4 ms·
Sorry no, i don't trust Shay Gueron either and, even if I did, I wouldn't trust what Intel, AWS or anybody else did after he left the building. Same goes for W
by nly 8y ago
Sorry no, i don't trust Shay Gueron either and, even if I did, I wouldn't trust what Intel, AWS or anybody else did after he left the building. Same goes for Whatsapp. It might be based on Moxies protocols and excellent work. I might trust Moxie, but I still don't trust WhatsApp to be eavesdrop free because I can't easily create compatible clients, inspect their protocol, or look at their code.
That's not to say you shouldn't use TPMs, HSMs, or CPU enclaves. It's just that, if at all possible, you shouldn't elevate them to being the only thing protecting you. In fact, most of these devices can be coupled with software encryption by splitting secrets between them and the users brain. My android phone for instance is encrypted, but only protected by a 6 digit PIN. I'm aware that I'm totally dependent on the SoC vendor here to rate-limit and otherwise fend off bruteforce attacks and protect the key ultimately protecting my data. But you know what? The encryption itself is still done in software and can be verified, and I have the choice to use a ridiculously long passphrase instead.
What Microsoft did is choose a stupid default, and put their users at unknown risk.
- tptacek 8y agoYou can have whatever criteria you'd like for trust. I'm familiar enough with the "open source security" argument on Hacker News to know where this discussion converges. I'm just offering a counterpoint: 1. Closed source wasn't too much of an obstacle for a pair of interested researchers to independently validate, without assistance from vendors, the firmware and hardware crypto interfaces on a bunch of drives. 2. The determinant of whether something is likely to be cryptographically sound is less likely to be "open source" (open source is full of cryptographically unsound things, many of which won't be ascertained as such for years to come) than whether you know the identities of the people who verified the design.
- nly 8y ago1. There's a difference between kicking the tyres and looking under the bonnet of a car, and taking the schematics and building your own. It's easier to show something is crap than convince people that it is good when you're outright hiding things. If the things you aren't hiding (well) are crap, then god only knows how terrible the things you are really hiding are. 2. Making claims based on the calibre of the companies and individuals involved doesn't work. People don't trust DJBs algorithms simply because of his personal track record. He also publishes whitepapers about their design, and demonstrates their advantages over the state of the art. That's hard science, not "it must be good because DJB is a rock star". The fact that people can then take his designs and implement them themselves, in the open, is also important.
- tptacek 8y agoI don't know many people who actually work in cryptography who believe that verification is cheaper and easier than building systems. People absolutely do, for the most part, trust DJB because of his track record. Find 10 people who have adopted Poly1305 and ask them what Poly1305 does better than GCM. That's not to say their decision is uninformed; rather, they've delegated a very specialized part of the decision that very few people are actually qualified to make out to an expert they trust, and trust for good reason. In practical cryptography, the opposite approach --- people who trust nothing until they verify it from first principles --- is extremely problematic. That's how you end up with oddball libraries that only look like they can do a secure scalar multiplication or reliably add two numbers together. As Bruce Schneier is fond of pointing out, everyone can design a system they themselves can't break.
- CiPHPerCoder 8y ago> Find 10 people who have adopted Poly1305 and ask them what Poly1305 does better than GCM. Two things, one of which cannot be credited to Poly1305 directly. 1. Poly1305 is easier to implement without introducing side-channels (modulo integer multiplication on some CPUs; in which case, I defer to Thomas Pornin on how to avoid them). 2. The Chapoly constructions that use Poly1305 do so in a way that leaking the one-time Poly1305 key doesn't buy you much. (This is the one that cannot be attributed to Poly1305 directly.) Others may have better or different answers. I implemented it in PHP [1], so anyone reading this thread should keep that in mind. :) [1] https://github.com/paragonie/sodium_compat/blob/f3b2d775a50d6f316b311554f4954a1668439551/src/Core/Poly1305/State.php https://github.com/paragonie/sodium_compat/blob/f3b2d775a50d...