Cooper Quintin writes: > Paul, > If you, as you say, "do not have much experience in breaking/testing > encryption or the details of modern methods", I must assume that you are > not, in fact a professional cryptographer. (That's okay! Neither am I!) > That being the case, I must ask you to PLEASE, PLEASE, PLEASE not > implement any sort of cryptographic solution yourself. ESPECIALLY if it > is intended to be used "under circumstances that the senders life may > depend on it being secure."
It seems even people with quite a bit of expertise often get crypto wrong in ways that can seriously undermine the resulting system's security. There are lots of examples. Sometimes the mistakes are a matter of not understanding the state of the art or the purposes for which a cryptographic operation is meant to be used. Sometimes they're about very subtle issues of information leakage that would have been hard to anticipate; two neat examples are timing attacks (where the amount of time that it takes for security-related code to run may reveal information including secret keys and passwords!) and recent attacks using information leakage from compression (whether compression succeeds in reducing the length of a message, and by how much, reveals information about the message's content). Application implementers wouldn't have thought that it's bad for different operations to take slightly different amounts of time (it turns out that even things like testing whether submitted_password == correct_password can be bad, because the amount of time it takes to fail can reveal which character of the submitted_password was wrong!); nor would they have thought that it could be bad to compress messages before encrypting them. But these simple decisions could lead to a complete compromise of the system. Another striking example about the need to understand the properties of one's crypto tools is the simple failure modes of ECB (traditionally the default block cipher mode!): https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 Check out the shadow penguin in the encrypted image. :-) I'm optimistic that systems like NaCl are going to help with some of this in the long run by providing useful abstractions that have most of the security properties that application developers would like, with immunity against many of the potential traps for the unwary. I'm not sure we're there yet, though. -- Seth Schoen <sch...@eff.org> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
