3 ms·
So he's advocating a particular block cipher (X25519)? (The online format made this hard to read.)
by teach 11y ago
So he's advocating a particular block cipher (X25519)?
(The online format made this hard to read.)
- wolf550e 11y agoCurve25519 does elliptic curve Diffie Hellman key exchange, not a cipher. The related Ed25519 does elliptic curve digital signatures. Both are used in modern crypto protocols like nacl and libsodium and both are being standardized for TLS. Newer versions of openssh use them with ssh. His cipher which is recommended together with those is chacha20. It is used with poly1305 MAC. It is a stream cipher, not a block cipher, and it is used with AEAD API. They too are already used in ssh and are being standardized for TLS. Chrome already uses them for TLS when talking to Google services if the client does not have hardware AES. https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Salsa20 https://en.wikipedia.org/wiki/Salsa20
- api 11y agoWe decided to use this cipher suite in our own product for some of the same reasons he mentions. Yet a lot of the general developer community is always like "Wut!?!?!? you didn't use AES!?!?" We've considered swapping it out or adding alternatives multiple times, especially when we were told that not being NIST/FIPS can lock you out of some enterprise markets. "Nobody ever got fired for using FIPS compliant crypto." But each time we've decided that the added complexity (and therefore attack surface, bugs, overhead, etc.) isn't worth it, especially since we have yet to find an actual concrete customer who turned us down because we're not FIPS. I'm very happy to see Google and OpenSSH implementing this stuff. It will really help with credibility among the non-crypto-savvy. "No, it's not FIPS, but Google and Apple use it." Side node: I worked once as a consultant with a government lab. Had to use FIPS. When vulnerabilities would come around, we'd have to scramble to harden our firewall because we couldn't upgrade to fixed versions because there was no FIPS-compliant fix yet. In some cases we had to run vulnerable. We also had to lag way behind on using smart card auth because the full stack wasn't FIPS yet on all Linux distributions. We were hacked once and none of the smart card auth'd systems got compromised, but much of the network did because it wasn't hardware access controlled yet... because of FIPS. If the conspiracy theories are right and FIPS (and NIST) are out to weaken crypto, it's working... but mostly for government and government-linked customers. Anyone who ignores FIPS and cargo-cult "best practices" is likely to be more secure.
- Spooky23 11y agoDon't attribute to malice what is more readily explained by incompetence. Most infosec people are glorified paper pushers, especially in regulated environments. What ends up happening is that "compliance" becomes synonymous with "security". This manifests itself in numerous ways, like spending millions on log systems like splint that nobody can access.
- Kristine1975 11y agoI think he advocates for crypto implementations that are provably secure. Provably secure = boring, because there are no security holes to be found. (the document gets much easier to read when viewed in single page mode)
- tveita 11y agoMaybe he's arguing for implementations that are provably correct, but I don't think DJB is a big fan of "provable security". https://twitter.com/hashbreaker/status/294465109613477889 https://twitter.com/hashbreaker/status/294465109613477889, "Some evidence that "provable security" is negatively correlated with actual security: http://cr.yp.to/talks/2013.01.23/slides.pdf http://cr.yp.to/talks/2013.01.23/slides.pdf "
- deleted 11y ago[deleted]
- wanderfowl 11y agoAgreed. Beamer's excellent, but for a static PDF which is not your intended presentation copy, it's cruel and unusual to expect people to read a copy with all the build steps.