3 ms·

It is idiosyncratic but it's not a bad recommendation, right? AES+HMAC-SHA2 would be AES-CTR and you would need to handle the nonce yourself, and that's not gr

It is idiosyncratic but it's not a bad recommendation, right? AES+HMAC-SHA2 would be AES-CTR and you would need to handle the nonce yourself, and that's not great. XChaCha is extended nonce, which should be safer. But there is no standard for extended nonce AES. Filippo Valsorda wrote that he would like XAES-256-GCM/11 [1] XChaCha looks like a good recommendation. Because lacking key commitment can lead to problems, a scheme that also gives you key commitment is better [2]? So that's not crazy. What does Google Tink do by default / recommend? What does Sophie Schmieg or whoever recommend? 1 - https://words.filippo.io/dispatches/xaes-256-gcm-11/ https://words.filippo.io/dispatches/xaes-256-gcm-11/ 2 - https://eprint.iacr.org/2020/1153.pdf https://eprint.iacr.org/2020/1153.pdf

tptacek 3y ago
I feel like it's not something I would recommend to someone that wasn't already very comfortable implementing and evaluating cryptography designs, is where I'm coming from. Key commitment is a pretty corner-casey problem. If I was designing a new competitor to AWS KMS, I would take it very seriously. If I was encrypting a cookie, which is, like, the modal and most representative motivating problem for authenticated encryption, I don't think I'd much care about it at all. The thing about commitment is, there's been a bunch of writing, and, especially, a bunch of conversation about it amongst cryptography nerds. It occupies a sort of similar space to KCI attacks. Like KCI, there are settings where it matters, but (1) even in those settings the attacks tend to be second-order things, and (2) those settings are kind of rare and specialized. But like: all the more important attacks on cryptography are basically solved problems! So this is what crypto nerds talk about. It doesn't follow from that that these are problems that should be top-of-mind for people building normal systems. I would not talk someone out of using Golang Seal/Unseal just to avoid KCI. I might talk about appending zeroes before I talked about hand-rolling an EtM just to avoid that problem.
- tptacek 3y ago
  I think I want to clarify this a bit, like: if you're building something like Noise, KCI matters a lot, because you're defining a generalized secure transport intended to be widely re-used, so you want to ratchet up the security promises you can make as far as they can reasonably go --- and even then there are Noise patterns that don't maximally address things like KCI? But most people most of the time aren't building and shouldn't build things like Noise. I'm the weirdo who thinks people like Trevor should build Noise, and generally other people shouldn't, because there's a whole lot of engineering context that you need to have to make sound decisions. It's one of several reasons I wouldn't feel qualified designing something like that. If you're _not_ designing a generalized reusable system --- and if you can get away with not doing that, you should, because reusability in cryptography designs ratchets up difficulty, which is the last thing you want with cryptography engineering --- then it is simply not the case that every design should be assiduously avoiding key commitment weaknesses.

tptacek 3y ago

I feel like it's not something I would recommend to someone that wasn't already very comfortable implementing and evaluating cryptography designs, is where I'm coming from. Key commitment is a pretty corner-casey problem. If I was designing a new competitor to AWS KMS, I would take it very seriously. If I was encrypting a cookie, which is, like, the modal and most representative motivating problem for authenticated encryption, I don't think I'd much care about it at all. The thing about commitment is, there's been a bunch of writing, and, especially, a bunch of conversation about it amongst cryptography nerds. It occupies a sort of similar space to KCI attacks. Like KCI, there are settings where it matters, but (1) even in those settings the attacks tend to be second-order things, and (2) those settings are kind of rare and specialized. But like: all the more important attacks on cryptography are basically solved problems! So this is what crypto nerds talk about. It doesn't follow from that that these are problems that should be top-of-mind for people building normal systems. I would not talk someone out of using Golang Seal/Unseal just to avoid KCI. I might talk about appending zeroes before I talked about hand-rolling an EtM just to avoid that problem.

tptacek 3y ago
I think I want to clarify this a bit, like: if you're building something like Noise, KCI matters a lot, because you're defining a generalized secure transport intended to be widely re-used, so you want to ratchet up the security promises you can make as far as they can reasonably go --- and even then there are Noise patterns that don't maximally address things like KCI? But most people most of the time aren't building and shouldn't build things like Noise. I'm the weirdo who thinks people like Trevor should build Noise, and generally other people shouldn't, because there's a whole lot of engineering context that you need to have to make sound decisions. It's one of several reasons I wouldn't feel qualified designing something like that. If you're _not_ designing a generalized reusable system --- and if you can get away with not doing that, you should, because reusability in cryptography designs ratchets up difficulty, which is the last thing you want with cryptography engineering --- then it is simply not the case that every design should be assiduously avoiding key commitment weaknesses.