On 3/4/08, Len Sassaman <rabbi(_at_)abditum(_dot_)com> wrote:
On Tue, 4 Mar 2008, David Crick wrote:
> I really would *ideally* like to see just one cipher suite, which I see
> could see would be: SHA384-AES256-ECC384_DH_DSA.
I'm with you on the one cipher suite. I think good protocols must have
methods by which new ciphers can be added (and implementors might actually
want to have them in the code and tested and ready should they need to
enable them), but the more options we add to a cipher suite, the more that
can go wrong.
(This is also my argument for why we should be using Whirlpool with AES,
but the counter argument of popularity/support for the second-gen SHAs
probably out-weighs it.)
Ian G. has written about this a lot, and he and I don't always agree on
everything, on this point, we do. OpenPGP already wants to do what I want
it to do; except the current notion is that if a cipher is broken,
everyone will disable support for it. That might have been a reasonable
assumption when only cypherpunks were using it, but it is naive now. If
you give the user a way to break their security, they will -- especially
if "not doing something" means breaking their security.
(As for which ciphers should go in, I'm going to remain agnostic. I would
pick differently than you did, but we all have our pet favorites. What
matters is that we limit the avenues of attack -- it's not about putting
all our eggs in one basket, as some confused people think; rather, it's
about limiting the possible crypto-level attacks on has available to them
when trying to break the system.)
--Len.
hey, you quoted my One Cipher choice without my corresponding
relevant justification! :) But yeah, I agree that others will disagree.
I think we *all* agree that we'd like to see ECC in OpenPGP
(and for those that don't, the current proposal appears to
supplement, not obsolete, 4880, so they can continue in
their non-ECC world). ECC will:
1) bring equiv. of 3K pub key to small devices
2) bring equiv. of 7 to 15K pub key to larger devices
3) allow OpenPGP to compete in the ECC marketplace
4) bring Suite B support (this is subset of some of the previous)
Now, we're currently fixating on the general topic of reducing
algorithms. AES192 seems to be departing without too much
protest, but 3DES (and the wider topic of 4880 compatibility)
seems to be the current "issue."
With V5 keys I think we're envisaging some form of incompatibility?
For instance, Daniel's recently posted "Thoughts and suggestions
on V5 key format" suggests using SHA512 for the fingerprint
(which I'd agree with given present specified 4880 hashes). Clearly
that would make SHA512 a MUST for V5 key applications - but it's
not even widely implemented/deployed yet (e.g. the last time I
checked, PGP9 wouldn't recognise SHA512 as a cert-digest-algo).
* So for me I think the whole ECC current point in question appears
to be: _when_ do we want to introduce ECC? Do we want to have
it as an alternative V4 choice (in which case we seem to, e.g., by
default allow 3DES with ECC), or do we wait until V5 (when we then
might be able to say: only AES with ECC) ? *
Now, let's say our user installs PGP 10 and is allowed to generate
a V4 ECC key.
Several years later ;) with PGP 12 they are prompted to generate
a different (V5) ECC key as the default. They are left wondering:
"didn't I already switch to the "new" ECC keys a few years ago???"
I think we want/need ECC in OpenPGP *soon*; I also think we need
to move away from SHA1/1024 bit IFP/DLP *soon* as well (where for
me, given various national and security bodies' recommendations,
"soon" = "by/before 2010").
So, do we try and do both together, or do we try and get ECC done
as a V4 alternative *now*, and think about V5 keys afterwards?
Thinking about is as I'm typing, I would favour ECC *first* and then
V5 after, the reason being that we're (hopefully!) likely to get
ECC consensus in a relatively short time, whereas V5 may take
longer and might/should also take into account the result of the
SHA3 contest, which isn't scheduled to finish until 2012. (We could
probably (??!) flesh out V5 before then, just leaving a gap for the
details on SHA3.)