qrmn

I think it might have rolled out already. Turn on Developer Mode in Windows 10 Anniversary Edition, and ssh to port 22 with a valid l/p?

Doesn't look like you even need to install WSL.

More permanent than a van. (Not that unusual for an embassy to be spied on!)

It might have something to do with the IMSI catcher installed more or less across the road; hard to hide those, they broadcast, and that one is not particularly trying to be stealthy.

Respectably, no tool - be it I2P's garlic routing, Tor's onion routing or anything else - could ever provide "complete untraceable anonymity"; that is a huge (and potentially very harmful) misunderstanding of what these techniques can do, I strongly encourage you to learn more about them to correct that misconception.

Both projects have designs which have inspired each other and have relative advantages and disadvantages. Technically, I like I2P, but I accept I may be somewhat biased there. Practically speaking, Tor has a much larger anonymity set because it is far more widely used and receives more support, with very well-established volunteer outproxies. I would never criticise anyone for contributing to either: Tor in particular has the widest practical impact of any tool in this space.

This distributed random idea is a very impressive achievement; I'm glad to see it work in the wild! Congratulations.

I'm not sure what you mean about "stigma". Any reasonably effective solution in such a politically-charged space as the anonymity and privacy of human communication is likely to become controversial to some degree.

Absolutely. I built a concept that essentially did that.

Separated program and data memory with only one executable. USB host would get (in hardware) an outright memory dump of the program memory on connection, so it could hash it/compare it to known-good firmware. If you flashed the firmware the data memory should get wiped, and if you flashed it with anything the driver didn't know as a good build, unless you manually whitelisted it, you'd be warned.

That seems like a better approach to me. (It turns out I really suck at designing hardware, let alone secure hardware.)

Doing the same kind of general thing with, say, a RISC-V microcontroller and trying to secure the RAM seems like a generally fruitful possible course of action? Let's see how Lowrisc turns out.

This is a hash function (as used in hash tables/Bloom filters and so forth), but it is not a cryptographic hash function. It is designed to be very fast for things like table lookups, but it is not designed to be strongly resistant to preimages, second-preimages, or collisions. Don't use it for security-relevant purposes.

I think BLAKE2 is probably the fastest and best cryptographic hash function you're likely to see for the foreseeable future?

I've experimented with doing this kind of thing myself, especially with servers where I don't have ready access to the console and where the provider doesn't offer custom ISO support and I wanted a clean (and/or customised) install, perhaps of something not yet supported.

While I did have some success with in-place install shenanigans, I eventually settled on creating a customised install ISO for the distribution I wanted (with a script to have it automatically listening for remote shell connections, and so on), using isohybrid on the ISO (which makes the ISO's first sector also a bootable MBR), and then simply dd if=install.iso of=/dev/sda - right over the top of the partition table and everything.

It's inelegant, to say the very least, but it works just fine! I'm pretty sure I saw that technique used a few times during Twitch Installs Arch Linux, during the more exotic segments when some joker hijacked the effort temporarily by installing Windows 95, and TempleOS, and so on.

XML was probably a mistake. Strong, deniable, end-to-end encryption should be mandatory. The Axolotl ratchet is the current state-of-the-art: maybe it does asymmetric things we don't need, or maybe that's helpful.

Looking forward: metadata protection. This is a much more difficult-to-solve problem, but existing tools such as Tor are partially successful.

As far as I'm aware, Yubikey 4 and Yubikey Nano 4 can do 4096; the older ones like the NEO can only do 2048.

Not that 2048 is flawed as such: it's still north of 100 bits workfactor at the moment, as far as I gather. 3072 would be equivalent to about 128 (similar to the EC algorithms secp256r1 or Curve25519), and 4096 is some extra insurance on top. (As a benchmark: Snowden used 4096-bit RSA keys for GnuPG.) Anything bigger than that could introduce OpenPGP compatibility troubles.

All of these are secure when correctly implemented. (Yubikey use NXP chips. I don't have much to say beyond that, I haven't audited them.) All of them will fall to Shor's algorithm on a quantum computer of sufficient size, but we're not likely to have one of those for a good few years, if they're possible.

Sybil is a real pain, and HashCash (via I2P, which had it as an anti-DoS option) was the first obvious attempt at a solution that worked. It would be better done with Argon2 now, but it still burns coal and is a bet that evil nodes don't have more power than all the good nodes put together - it seems we aren't always going to win that bet.

Will proof-of-stake would be any better? It doesn't feel as suited to things other than currency to me, because: what value does the deposit have? We'll see how it turns out when deployed, it's hard to predict how people will react.

There's a surprising amount of heat in the field now. Lots of activity, like this interesting work, some very strong opinions. Please don't eat me! I'm quite happy to leave it be and move onto other things.

I do have an "invite" prompt on my SMS contacts that don't yet have Signal: "Invite to Signal: Take your conversation with %s to the next level.". Perhaps it's a function in the beta version that isn't in the live version yet?

I haven't seen a message with a double-tick that's been dropped yet, at least not on a recent version. It can sometimes behave poorly with Android battery-saving mode - however, so does plain SMS. Turning off sync is part of the actual point of battery-saving, but conversely, I never want to not get messages. That's arguably Android's problem, not Signal's. Still, it uses GCM, so at least there's hope for the deep sleep (which I haven't tried yet).

Impossible is a strong word - one prefers to reserve that for provably doomed problems like DRM - but several common, simple paradigms do present an unexpected technical challenge, or even an open research problem, or need to be expressed slightly differently to be practical, in a distributed, privacy-preserving, untrusted-server kind of model.

For example, paraphrasing quite a lot - uniqueness of names requires ordering; ordering probably requires consensus; consensus has a Sybil problem for which some kind of countermeasure is needed. So a namespacing problem that seems simple, and is simple in a centralised/trusted context, may only be practical to solve with a blockchain-like structure with a computationally-heavy proof-of-work in a distributed trust architecture. Even that may still be vulnerable to attacks from someone who can outcompute the rest of the network: and a Nation State Adversary (as a friend snarkily puts it) may actually have enough budget to try that. There may be another way, but maybe not another way that satisfies all the security requirements or that would survive an attack. And there are still other niches you need to worry about, like homoglyph attacks.

That's a long way to go just to make sure that there aren't two ~bobs! So you end up thinking, maybe it's better to find another way that ~alice knows she's talking to the right ~bob? Then you have rephrased your security problem as more of a UX problem: how do I try to avoid impersonation? - which is perhaps more practical to solve another way. [Edit: Also, now your users won't have to fight over who gets to take ~bob first. This may or may not be an advantage, depending on how you feel about username exclusivity.]

It's going to require a lot of hard work to solve this type of problem comprehensively; in the meantime, Signal does more or less the best we can do practically right now, and there's a lot of value in a practical solution that's best-in-class, works and millions of people can just pick up and use now.

I wish that were true, but honestly, plaintext isn't fine for anything at all in 2015, whether authenticated, important, public or otherwise, whether the network is the internet or a LAN.

HTTP sites have had attack scripts injected into them by nation-states, used to DDoS others on a massive scale - and that capability, and the desire to use it, is unfortunately proliferating rapidly.

Unless you want to be part of that problem, you're going to have to go HTTPS on everything - cat videos included - no matter how important or unimportant you think it is. I really wouldn't be surprised if tcp/80 goes the way of tcp/23.

On a brighter note - the speed difference is negligible with modern cryptography, and as others have mentioned, TLS 1.3 is developing handshakes with less TCP round trips. It's possible that a future protocol (taking into account what's been learned by Google's QUIC experiment) may deliver faster handshakes over UDP if possible to avoid the TCP handshake overhead - there's energetic research in that area at the moment.

This is a very solid point. We already had an open cryptographic competition to select a password hashing standard, and we have a winner: Argon2 is being developed as a new standardised password hash (i.e. slow-hash).

If you're going to introduce a new one, it should go through at least the same level of cryptanalytic scrutiny before anyone uses it.