[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ECC in OpenPGP proposal, second revision
David Crick wrote:
11.1 I would like to see "MAY implement curve ID 2" explicitly stated
(this *is* mentioned in section 12, but would like to see it here too)
11.3 says "The best remedy to this .. is to add .. AES-256"
not sure about "best" - perhaps "simplest"? The reason being is
that as AES128 is an ECC must, then this guarantees us *a* Suite
B acceptable cipher, although - as you're trying to get at - having
AES256 means that we'd cover *both* Suite B profiles.
I'm not sure if I agree with the sentiment of "adding .. to .. each
recipient's key" - doesn't quite sound right? (Maybe because it
sounds like sender coercion, rather than a higher-level admin
With the mentioned correction this is one of possible alternatives. It
is one of cleanest fixes in the sense of standard correctness. I realize
that it is not a practical fix for the incompatibility. I can't fix the
keys at at the moment I am sending a message. That's why we should
mention the importance of proper key preferences in reference to
12 "It is generally advisable to list at the head of the preference list
a symmetric algorithm of strength corresponding to the public key."
I watered down this statement to leave that at least the algorithm
should be there.
Again, I see what you're trying to say, but as is noted elsewhere in
the ECC doc, it's merely the intersection - it's up to the implementation
to make its own decision thereafter (and so take advantage of any
As a side note, per RFC4880 this "is an ordered list of octets with the
most preferred listed firs". If each recipient has the same set of
symmetric algorithms, shouldn't the intersection remain ordered? I think
"merely an intersection" is not strictly correct, although I can agree
with "in practice" or "in most cases" clarification.
I think section 12 also needs to explicitly deprecate AES-192, saying
that it's not necessarily going to be fielded widely (bring in the fact
that it is only a MAY here might help), isn't one of the Suite B ciphers,
and that it's probably only suitable if for some reason you *really*
need a 192-bit cipher: otherwise go for AES256 for security or -128
I hope that we find a consensus in not explicitly promoting AES-192
instead. There are many reasons why mobile/weak hardware devices may
wish the middle-of-the-road approach with AES-192/ECC-384.
The evidence regarding performance shortcoming of AES-192 is not
On http://www.cryptopp.com/benchmarks.html AES/ECB 192 appears even
faster than 128 in key setup (a measurement aberration, perhaps). The
data encoding speed is decreasing smoothly for 128/192/256 keys with a
So is data encoding performance in http://www.linux.com/feature/114024
for AES 128/192/256 with CBC for both 16 bytes and 8192 bytes. The
throughput is reduced by a factor ~1.15 as we go to stronger AES.
GnuPG shows gradual slowdown for AES 128/192/256
http://www.nchelp.org/committees/cl-elec-exch/msg00734.html. The factor
If we were to discourage AES-192, we will need convincing references to
data that support and explain our choice.
overall, though, I think we're getting there.
The latest version is:
The same version in other formats: