[114840] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Gutmann Soundwave Therapy

daemon@ATHENA.MIT.EDU (Leichter, Jerry)
Sat Feb 9 20:10:29 2008

Date: Fri, 8 Feb 2008 09:12:33 -0500 (EST)
From: "Leichter, Jerry" <leichter_jerrold@emc.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
cc: cryptography@metzdowd.com, ekr@networkresonance.com, guus@sliepen.org,
        jamesd@echeque.com, krstic@solarsail.hcs.harvard.edu
In-Reply-To: <E1JNO9C-0007OG-2i@wintermute01.cs.auckland.ac.nz>

| >All of this ignores a significant issue:  Are keying and encryption
| >(and authentication) mechanisms really independent of each other? I'm
| >not aware of much work in this direction.
| 
| Is there much work to be done here?  If you view the keyex mechanism
| as a producer of an authenticated blob of shared secrecy and the
| post-keyex portions (data transfer or whatever you're doing) as a
| consumer of said blob, with a PRF as impedance-matcher (as is done by
| SSL/TLS, SSH, IPsec, ..., with varying degrees of aplomb, and in a
| more limited store-and-forward context PGP, S/MIME, ...), is there
| much more to consider?
I don't know.  Can you prove that your way of looking at it is valid?
After all, I can look at encryption as applying a PRF to a data
stream, and authentication as computing a keyed one-way function (or
something) - so is there anything to prove about whether I can choose
and combine them independently?  About whether Encrypt-then-MAC and
MAC-then-Encrypt are equivalent?

I should think by now that we've learned how delicate our cryptographic
primitives can be - and how difficult it can be to compose them in a
way that retains all their individual guarantees.

							-- Jerry

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

home help back first fref pref prev next nref lref last post