3 ms·

"Colin should account for the fact that there's a significant set of practical attacks that his approach to cryptography doesn't address: side channels. All the

"Colin should account for the fact that there's a significant set of practical attacks that his approach to cryptography doesn't address: side channels. All the proofs in the world don't help you if the branch target buffer on the CPU you share with 10 other anonymous EC2 users is effectively recording traces of your key information." Well, it is not practical, but you can prove that an algorithm has no side channels e.g. you can use the construction of Pippenger and Fischer to create an oblivious version of any algorithm. To put it another way, if you could not prove that there were no side channels in an algorithm, you could never prove the security of something like FHE. Even if we assumed a perfect world where implementations were never wrong, practical concerns would still be a drag on the value of security proofs. We do not use AES because we can prove it is secure; we use it because it is fast and "secure enough." "Those people, the people designing systems based on what they read in _Applied Cryptography_, badly need to understand crypto attacks before they put code based on their own crypto decisions into production." I am not sure understanding the particular attacks we know so far is really important here. More than anything, I think people need to understand that attacks in general occur where abstractions fail. The closer you stick to the abstraction assumed in a security proof, the more secure your system will be (ignoring implementation bugs). If ever there was a place where premature optimization is a bad idea, it is in the implementation of cryptosystems.

tptacek 13y ago
I don't understand your first point, but that could just be the flu talking. The second point though, I think the opposite is true. You need to understand in your gut that parameters to number-theoretic crypto can be proposed specifically to make your math fail; you need to understand that even if flipping a single bit in your ciphertext garbles the output, that attackers can do useful things with that property; you need to understand that being able to coerce a system into producing the same ciphertext block for the same plaintext block admits terrible attacks; you need to understand where systems "want" randomness versus where they absolutely require it. It's not enough to know that errors "happen". You have to be able to predict them.

tptacek 13y ago

I don't understand your first point, but that could just be the flu talking. The second point though, I think the opposite is true. You need to understand in your gut that parameters to number-theoretic crypto can be proposed specifically to make your math fail; you need to understand that even if flipping a single bit in your ciphertext garbles the output, that attackers can do useful things with that property; you need to understand that being able to coerce a system into producing the same ciphertext block for the same plaintext block admits terrible attacks; you need to understand where systems "want" randomness versus where they absolutely require it. It's not enough to know that errors "happen". You have to be able to predict them.