ietf-openpgp
[Top] [All Lists]

Re: ECC in OpenPGP proposal, second revision

2008-03-17 02:57:55

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.


Corrected.

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
led policy?)

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 relative security.



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
ordering information).

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
for performance.

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 overwhelming.

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 factor ~1.13.

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 is ~1.03.

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:
   http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-8.txt

The same version in other formats:
   http://brainhub.googlepages.com/pgp