On Sun, May 14, 2006 at 03:04:41AM -0500, Travis H. wrote: > Suppose I want a function to provide integrity and authentication, and > that is to be combined with a stream cipher (as is the plaintext). I > believe that authentication is free once I have integrity given the > fact that the hash value is superencrypted using the stream cipher, > whose key is shared by only the sender and recipient. I believe what > I'm looking for is a strongly universal hash. I don't need much; > everything I've seen is simultaneously too much and too little, often > calling upon a block cipher, which seems redundant. > > What I was thinking of doing was using Poly1305, and using the stream > cipher instead of AES. I think in this case that I can leave the MAC > exposed, since it's a MAC and not a hash. Is there an analogous, hash > function that does not use encryption internally? >
Security is fragile. Deviating from well understood primitives may be good research, but is not good engineering. Especially fragile are: - Non-mainstream ciphers (often broken once someone good bothers to try) - Stream ciphers (additive) - RC4 (poor key schedule) - RSA (multiplicative) The first is to be avoided entirely, the second and third should be used only under duress, when block ciphers are a very poor fit for the application. RSA needs to be used only in very specific ways (PKCS 2.1, for example) that avoid the common pitfalls. TLS (available via OpenSSL) provides integrity and authentication, any reason to re-invent the wheel? It took multiple iterations of design improvements to get TLS right, even though it was designed by experts. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAIL Morgan Stanley confidentiality or privilege, and use is prohibited. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]