Hi Adam,
Yes, the two application-level requirements of secure storage and secure
transmission have radically different temporal properties. Just as an
example, secured storage of email using PGP or MIME actually works less
well than the alternate - nothing - because it requires the user to
maintain copies of old keys ... which they typically don't. An
unreadable email is not a secure one, it's a fail. These systems
exhibit killer pathologies that teach users never to make the mistake of
using them ever again. User-less is equivalent to useless.
iang
On 26/04/12 20:39 PM, Adam Back wrote:
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
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
