3 ms·

We've discussed much of this before on HN, and I am slowly but surely starting to see exactly what you mean. Getting everything in crypto just right is a hard p

We've discussed much of this before on HN, and I am slowly but surely starting to see exactly what you mean. Getting everything in crypto just right is a hard problem, especially with the disparity between different crypto providers and how it should be implemented to be secure. The biggest issue I have is that unless low level primitives are available it is hard to work together with various other libraries/standards. Getting Java and OpenSSL based crypto to play nice is already harder than it should be, I can't imagine what a mess it would be to try to make it work with yet another standard. And at the same time if those low-level primitives are available people are going to use them instead of the higher-level functions because they have certain specific requirements. --- Any specific reason as to why AES-CBC? If seeking is required wouldn't AES-CTR be a better choice? Or are you making assumptions that the payload size is small enough that decryption of the whole object is feasible?

tptacek 14y ago
Seeking is a great example of something that you would think you'd want in a crypto API that has pitfalls when you implement it in a real cryptosystem. And it looks to me like this proposal wants to support seeking, and doesn't account for those pitfalls. And I think you're right: I think the interface proposed here is idiosyncratic enough that it will be difficult to make it interoperable, but that idiosyncrasy doesn't buy any additional security.
ctz 14y ago
> Any specific reason as to why AES-CBC? If seeking is required wouldn't AES-CTR be a better choice? Or are you making assumptions that the payload size is small enough that decryption of the whole object is feasible? Choosing nonces is hard. For a given key, nonce reuse with AES-CBC fails leaking plaintext equality of the first blocks of the two messages. This is bad. AES-CTR usually fails by leaking the entire two plaintexts. This is catastrophic. Cobbling together AEAD schemes out of AES-unauthenticated-anything and HMAC-anything is a poor idea, and unnecessary. AES-GCM and AES-CCM are here, standard and performant. Use them.
- tptacek 14y ago
  Choosing nonces/start states for CTR is no harder than choosing IV's for CBC, but the impact of choosing the wrong CTR IV is more easily exploitable. A bigger issue is that even if you get the IV right, there are other things that can go wrong with CTR mode.

tptacek 14y ago

Seeking is a great example of something that you would think you'd want in a crypto API that has pitfalls when you implement it in a real cryptosystem. And it looks to me like this proposal wants to support seeking, and doesn't account for those pitfalls. And I think you're right: I think the interface proposed here is idiosyncratic enough that it will be difficult to make it interoperable, but that idiosyncrasy doesn't buy any additional security.

ctz 14y ago

> Any specific reason as to why AES-CBC? If seeking is required wouldn't AES-CTR be a better choice? Or are you making assumptions that the payload size is small enough that decryption of the whole object is feasible? Choosing nonces is hard. For a given key, nonce reuse with AES-CBC fails leaking plaintext equality of the first blocks of the two messages. This is bad. AES-CTR usually fails by leaking the entire two plaintexts. This is catastrophic. Cobbling together AEAD schemes out of AES-unauthenticated-anything and HMAC-anything is a poor idea, and unnecessary. AES-GCM and AES-CCM are here, standard and performant. Use them.

tptacek 14y ago
Choosing nonces/start states for CTR is no harder than choosing IV's for CBC, but the impact of choosing the wrong CTR IV is more easily exploitable. A bigger issue is that even if you get the IV right, there are other things that can go wrong with CTR mode.