Live data from Hacker News

Cryptographic Right Answers

latacora.singles

151–160 of 243 posts

Re: Cryptographic Right Answers

#151

Earlier quoted context omitted.

Which of those answers are going to hold up in the post-quantum world?

Asymmetric crypto (RSA, curve25519, etc.) and Diffie-Hellman (including ECDH) are both in danger, thanks to Shor’s algorithm. I think the only thing remaining is large-enough quantum computers. If I remember correctly, hashes and symmetric crypto are generally safe, and so those recommendations shouldn’t change.

The effective keysize for symmetric crypto can be cut in half by quantum computers by Grover's algorithm, so just make sure you use 256-bit keys rather than 128-bit keys.

Re: Cryptographic Right Answers

#152
post #48

Earlier quoted context omitted.

Does this hold for other AWS services that manage https endpoints? Especially Cloudfront which seems to be the de facto solution for anything serverless. Integration with ACM obviously also comes out of the box, but I haven’t looked under the hood at the implementation (besides IIRC a « you can have any color provided it’s black » approach to security options)

I'm not sure I follow with Cloudfront serverless but generally: sure? I don't like giving blanket recommendations when I haven't audited everything I'm recommending but generally speaking: yes.

By cloudfront and serverless, I mean that if you want S3 hosting + https you need a Clousfront distribution. If you use a custom domain name with your API GW there’s a Cloudfront distribution created behind the scenes. And I believe the same holds for Lambda@edge. In other words, if you’re not relying on VMs + ELB (or Elastic Beanstalk) to host your application, it seems that the only way to use an https certificate is through Cloudfront.

Re: Cryptographic Right Answers

#153
post #134
post #115

Earlier quoted context omitted.

What's wrong with PolarSSL/Mbed TLS? It is designed for low-end ARM processors and is directly backed by ARM.

Their history of implementation issues leads me to believe that the general upside of TLS doesn’t necessarily weigh up to the upside (and cost!) of a light bespoke implementation. That’s contingent on having someone around who won’t mess this up; failing that, an embedded TLS stack is still a good idea. I would have told you something differently before NOISE and NaCl, particularly Curve25519. We could have done AESC…

I don't think you can deem mbedTLS too risky on one hand, and then on the other recommend Noise, with it's slew of unfinished and largely unverified libraries. Outside of the WireGuard RHUL effort for a specific 'pattern' AFAIK the Noise core hasn't really seen any formal analysis either. Commoditizing the DH operation means you can build an enormous amount of AKEs, and even people like Trevor Perrin can make mistakes there.

Noise is potentially very interesting, particularly for the embedded space, but it'll be a while before it's safe to use.

Re: Cryptographic Right Answers

#154
post #2

Fight me. I mean, happy to answer any questions. By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter: https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&... This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not…

Question, I build webapps, meaning I only have access to the native WebCrypto API that doesn't have some of these other things mentioned. Advice/pointers? Here is our setup: ECDSA sign/verify P-256; ECDH enc/dec P-256; PBKDF2 password + salt = extension, using SHA-256, 5000 iterations, 64 ks; private key encrypted with PBKDF2 extension via AES-CBC But it isn't like WebCrypto gives you access to much else. So given br…

5000 iterations of PBKDF2 is very low. I'd use at least 100,000. Benchmark it, but that should be reasonable even on mobile provided you're caching the keys.

Re: Cryptographic Right Answers

#156
post #41

Earlier quoted context omitted.

As implemented in jedisct1's libraries, it allows authenticating associated data, unlike XSalsaPoly from NaCl.

ChaCha is generally faster and has more implementations, including OpenSSL. Salsa is essentially limited to NaCl and Sodium. From a security perspective, there is nothing wrong with Salsa. But libraries implementing ChaCha today are unlikely to add Salsa. It wouldn't take much effort for libraries currently having high-quality implementations of ChaCha to add an extended nonce variant. The only reason it didn't happe…

It may help if we point out that we now have at least two independent implementations of XChacha20: your Libsodium and my Monocypher. This should raise confidence.

I'd love to add the extended nonce to RFC 7539, though.

Re: Cryptographic Right Answers

#157

Can anyone recommend some good cryptography books/links for someone that would like get up to speed on best practices for building secure systems? Ideally the full gamut of beginner to advanced. What are the classic/authoritative texts in this space?

https://www.crypto101.io/

Re: Cryptographic Right Answers

#158
post #145
post #2

Fight me. I mean, happy to answer any questions. By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter: https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&... This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not…

Is it problematic that we're moving to a djb crypto monoculture, with 25519 and ChaCha and Poly1305 and even NaCl all as recommendations? Or is he the hero we need to fight bad or weakened crypto? I've loved the CryptoPals series, even just reading the challenges for the more advanced parts while I poke at the easier stuff. Please keep them up, and hopefully I'll get all the way through "Shackling the Masses with Dra…

DJB's primitives are generally simpler than what came before. They're easy to implement, pretty easy to immunise against timing attacks, and relatively easy to review.

So we're not just trusting DJB here. We're trusting a sizeable community that reviewed his work.

Re: Cryptographic Right Answers

#159

Here is a summary, roughly ordered from constant to changed the most. Percival Ptacek Latacora 2009 2015 2018 Online backups tarsnap tarsnap tarsnap Symmetric key length 256-bit 256-bit 256 bit Symmetric “Signatures” HMAC HMAC HMAC Random IDs 256-bit 256-bit 256-bit Hashing algorithm SHA256 (SHA-2) SHA-2 SHA-2 Password handling scrypt scrypt scrypt PBKDF2 bcrypt argon2 PBKDF2 bcrypt PBKDF2 Website security OpenSSL Op…

[deleted]

Re: Cryptographic Right Answers

#160

Here is a summary, roughly ordered from constant to changed the most. Percival Ptacek Latacora 2009 2015 2018 Online backups tarsnap tarsnap tarsnap Symmetric key length 256-bit 256-bit 256 bit Symmetric “Signatures” HMAC HMAC HMAC Random IDs 256-bit 256-bit 256-bit Hashing algorithm SHA256 (SHA-2) SHA-2 SHA-2 Password handling scrypt scrypt scrypt PBKDF2 bcrypt argon2 PBKDF2 bcrypt PBKDF2 Website security OpenSSL Op…

Quick update though: for client-server security, I copy-paste misquoted Colin and just now noticed it (because Colin noticed it for me). The 2015 document correctly says Colin's client-server recommendation is "custom RSA protocol", but when I formatted this document I managed to accidentally make it say the same as his recommendation for "website security". I regret the error (but not the recommendation; don't make…

[deleted]
Post reply on HN