I wish XChaChaPoly was more widely implemented.
Why?
Cryptographic Right Answers
41–50 of 243 posts
Re: Cryptographic Right Answers
#42Fight 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…
Hey, can you share some crypto advice for limited embedded systems (let's say minimum being 32bit cortex-M0). Say for firmware updates, user data uploading, etc.
Embedded crypto gets weird fast. General recommendations are a little tricky, but: is that device talking to the internet directly or some kind of IoT hub or whatever?
Re: Cryptographic Right Answers
#43I just found that AES-CTR + HMAC is very simple and doable in in languages like Go and Javascript for large objects which can't (or shouldn't) all be put into memory at the same time. In fact, a popular google drive client uses this: https://github.com/odeke-em/drive/wiki/End-to-End-Encryption
(assuming standard secure key generation for both the AES-CTR stream and the HMAC - along with a unique IV)
However, reading this article it seems this might no longer be recommended.
Re: Cryptographic Right Answers
#44> Encrypting Data Percival, 2009: AES-CTR with HMAC. I just found that AES-CTR + HMAC is very simple and doable in in languages like Go and Javascript for large objects which can't (or shouldn't) all be put into memory at the same time. In fact, a popular google drive client uses this: https://github.com/odeke-em/drive/wiki/End-to-End-Encryption (assuming standard secure key generation for both the AES-CTR stream and…
XSalsa20Poly1305 can also be implemented in a streaming/buffered fashion, it's just that most libraries implement the easier to use interface.
If you're encrypting objects that won't fit in RAM, it's worth considering encrypting separate chunks, making sure that the order cannot be changed (e.g. by incrementing a part of nonce for each chunk and setting some flag for the last chunk, see https://github.com/dchest/nacl-stream-js or https://download.libsodium.org/doc/secret-key_cryptography/s...). This allows detecting tampering early without writing malicious results into a file. Again, should be done carefully, as it's easy to get wrong.
Re: Cryptographic Right Answers
#45Fight 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…
I think the most useful parts of the document are the 'really try hard to use TLS for any comms problem' or 'try to use Amazon's key management for encryption' answers, and pointers to good libraries. Beyond that: developers aren't normally tasked with building systems out of cryptographic primitives. Those that do are typically (hopefully!) experienced enough to pick a solid primitive. Those who need to look-up whic…
FWIW I'm more hopeful that I can make mTLS work immanently as part of the environment than everyone getting it right in their app. Less httpd more caddy, if that makes sense :)
Re: Cryptographic Right Answers
#46Earlier quoted context omitted.
1) Yes, use SHA512/256 (truncated SHA512). I don't think I'd default to SHA3 anywhere. 2) Are you entirely convinced you actually need client tokens? In particular, can you get away with a 256-bit random token and store the session in a database? 3) Re: HMAC input malleability: yep, concat and HMAC is fine. Serializing JSON or whatever is also fine. You're usually providing the tag (that's what the output of HMAC is…
1) Huh. Weird it exists at all then. 2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn't need to look up a valid token upon every request--which scales better. In my case, the API endpoint is for something that doesn't (and won't) get a lot of traffic, so I can probably get away with a 256-bit random token over TLS? Since it's over TLS, there pr…
Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0].
Re: Cryptographic Right Answers
#47Re: Cryptographic Right Answers
#48Earlier quoted context omitted.
(Hi I'm not tptacek but I am also a Latacora principal and I co-edited this new version of the document) When you're setting up ELB today you're probably getting ELBv2, specifically an ALB (since we're discussing TLS termination here). There are a few things I like a lot about the way you do TLS configuration for an ALB, but notably: * Instead of giving you the ability to configure literally everything, they have a h…
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)
Re: Cryptographic Right Answers
#49> Encrypting Data Percival, 2009: AES-CTR with HMAC. I just found that AES-CTR + HMAC is very simple and doable in in languages like Go and Javascript for large objects which can't (or shouldn't) all be put into memory at the same time. In fact, a popular google drive client uses this: https://github.com/odeke-em/drive/wiki/End-to-End-Encryption (assuming standard secure key generation for both the AES-CTR stream and…
It's not recommended not because it's insecure, but because it's easy to get wrong. XSalsa20Poly1305 can also be implemented in a streaming/buffered fashion, it's just that most libraries implement the easier to use interface. If you're encrypting objects that won't fit in RAM, it's worth considering encrypting separate chunks, making sure that the order cannot be changed (e.g. by incrementing a part of nonce for eac…
Re: Cryptographic Right Answers
#50Earlier quoted context omitted.
Hey, can you share some crypto advice for limited embedded systems (let's say minimum being 32bit cortex-M0). Say for firmware updates, user data uploading, etc.
Use Monocypher, TweetNaCl, or Libsodium. Monocypher is portable (C99/C++), pretty fast, and has low memory footprint (generated binary between 30kB and 60kB). Problem: it isn't trusted yet. (I'd like to run a bug bounty, but I'm not sure how I should go about it.) TweetNaCl is portable (C89), has low memory footprint, and is made by trustworthy professional cryptographers. Problem: it is slow . Libsodium is blazing f…