Advice: if you're creating something for general-purpose use, at a minimum make sure it provides authentication, integrity, *and* confidentiality. A reasonable choice might be Encrypt-then-Authenticate where you first encrypt with AES-CBC, then append a AES-CMAC message authentication code on the ciphertext (including the IV). As a bonus, this will detect decrypting with the wrong key.
Use key separation -- with a pseudorandom function -- to derive the encryption key and authentication key from the master crypto key supplied by the user: e.g., Encryptkey = AES(K, all-zeros), Authkey = AES(K, all-ones). (You could replace AES-CMAC with SHA1-HMAC, but why would you want to?) (From a cryptotheory point of view, what you want is a mode of operation that meets IND-CCA2 /\ INT-CTXT, or at least IND-CCA2 /\ INT-PTXT.) Advice: Provide one mode, and make it secure. Try to avoid configurability, because then someone will choose a poor configuration. Suggestion: Provide documentation to warn the programmer against using a password (or something based on a password) as the crypto key. Provide support for PBKDF2, with a reasonable default choice of parameters and appropriate warnings in the documentation, for those who absolutely must use a password-derived crypto key. Recommendation: Read the book Practical Cryptography by Ferguson and Schneier, or at least the chapters on message security. It's the best source I know to teach you some of the crypto-engineering practicum. Kevin W. Wall wrote: >I have considered using an HMAC-SHA1 as a keyless MIC to do this, >using something like: > > MIC = HMAC-SHA1( nonce, IV + secretKey ) >or > MIC = HMAC-SHA1( nonce, IV + plaintext ) > >and then also include the random nonce and the MIC itself in the CipherText >class so it can be validated later by the decrypter, with the understanding >that the plaintext resulting from the decryption operation should only be >used if the MIC can be properly validated. (Probably an exception would >be thrown if the dsig was not valid so there would be no choice.) I would not recommend either of these. It's better to use a MAC as I suggest at the top of this email. Whatever you do, don't choose your second MIC option: if the plaintext comes from a low-entropy space, it leaks the value of the plaintext (the plaintext can be recovered by brute-force search over all possible plaintexts). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
