I thought of another example along the principle separate keys for different security properties Zooko discussed earlier in this thread.
In the distant past on the openpgp there was some discussion about separating storage and communication keys (it was related to an egress corporate key escrow feature called the ADK additional decrypt key). It is IMO bad practice that PGP (and SMIME) mixes storage and communications keys. Communication keys should be backward secure (aka forward secret) cf draft on forward secrecy extensions for PGP with Ian Brown & Ben Laurie some years ago: http://tools.ietf.org/html/draft-brown-pgp-pfs-03 For forward secrecy communication keys should be destroyed after use, whereas storage keys have their own lifecycle management features. They should be managed for archive features, and document retention/destruction etc. If you combine them you end up with a compromised design in both dimensions. Adam On Thu, Apr 26, 2012 at 11:55:27AM +0200, Adam Back wrote:
I think the separate integrity tag is more general, flexible and more secure where the flexibility is needed. Tahoe has more complex requirements and hence needds to make use of a separate integrity tag. I guess in general it is going to be more general, flexible if there are separate keys (including none with keyless self-authenticated URLs) for different properties. Hence there remains a need for separate integrity and encryption even with authenticated encryption modes. And typically AE modes have a cost - several of the standardized encryption modes are actually just standardizing ways to combine separate integrity & encryption primitives. The others are mostly patented. They tend to be more fragile through binary reliance on strictly one use nonces, XOR via counter mode and such modes which are I think in implementation terms unforgiving or fragile. Exercise for the reader to list the non-patented, non-trivial (combining an integrity & encryption primitive) modes :) Adam
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
