general defensive crypto coding principles

Anton Stiglic astiglic at okiok.com
Mon Feb 13 23:28:42 EST 2006


I don't believe MtE is good advice, and I have yet to see a decent reason
why one would want to use that instead of EtM. 
Of course when we talk about EtM, the MAC should be applied over all
plaintext headers and trailers (including IV used for encryption, algorithm
identifier, protocol version, whatever).

Allot of attacks could have been prevented with EtM, including the Vaudenay
padding attack, the Chosen-Ciphertext Attacks against PGP and other email
encryption protocols described by Schneier, Katz and Jallad
http://www.schneier.com/paper-pgp.pdf
as well as the attacks on Host Security Modules key blocks (well in this
case the bad was simply that their were to integrity checks, 2 key
Triple-DES keys were protected by a master triple-DES key by encrypted the
left part and right part independently) and other such types as described by
Clulow and others
http://www.cl.cam.ac.uk/~jc407/Chap3.pdf

Ferguson gave an explanation why in his book with Schneier they recommend
MtE
http://groups.google.ca/group/sci.crypt/msg/1a0e0165c48e4fe4?q=g:thl19936885
73d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8
But the arguments he gives pertain to other problems; see for example the
comments given by Wagner which I agree with
http://groups.google.ca/group/sci.crypt/msg/532fdfb5edca19a8?q=g:thl24955674
08d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8

I had come up with a list of advices for crypto implementation some time ago
myself.  These included (from memory)

- Use good RNGs, even for things other than the generation of keys (such as
for generating IVs, challenges, etc.)
- Use standard algorithms, and use them in secure ways (choose a good mode
of encryption, adequate key sizes, pick the IVs the way you are supposed to
securely, usually either randomly or for counters make sure you have no
repeats)
- Use standard protocols (don't try to re-invent TLS or IPSec)
- Encrypt then authenticate over ciphertext and all plaintext headers and
trailers.
- Use independent keys for different functionalities.  If needed, derive
independent keys based on a single secret using a good key derivation
function.
- Limit the amount of time you handle secrets (zeroize after use...)
- Don't let yourself be used as a random oracle (I think Ross Anderson said
it this way first), this includes limiting information that is leaked about
errors, avoiding timing attacks and such (this is hard to do in practice).

--Anton




-- 
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.1/250 - Release Date: 03/02/2006
 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list