[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ECC in OpenPGP proposal
I respectfully remind you that the target of this proposal is 1) to
better match AES key strength with OpenPGP by extending RFC 4880, 2) to
meet Suite-B, 3) to offer more usable alternative for mobile/embedded
Suite B is limited to section 11.2. Suite B will have limited
interoperability with RFC 4880, just like currently FIPS certification
is incompatible with RFC 4880. Most of your comments in this e-mail
apply to small section 11.2.
The discussion earlier was mostly about OpenPGP ECC keys that are
compatible with RFC 4880.
Ian G wrote:
OK, I think I found it. Sorry for not keeping up!
Daniel A. Nagy wrote:
I think, Andrey makes a very important point here. The option to use
symmetric encryption, SHA1 digest and ZLIB compression must remain
a formal process of phasing them out is initiated, with a clear road
Right now, excluding these algorithms would break interoperability in
bad way, as described by Andrey.
I disagree, below :)
Of course, SHA1 and 3DES are not without problems, but for most
security-critical applications they are still perfectly adequate.
Right. The question is not about the security of the algorithms
(which are more or less Pareto-secure-ish). Instead, it is about the
business aspects of delivering the most security to the most people.
On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote:
David Crick wrote:
The ecc-pre-6.txt's section 2 pretty much says "this is how to
do ECC with AES," and we've said that this proposal is a "MAY."
In a sense this is therefore some kind of a fork (sub-superset?)
of 4880, so we're not concerned with 3DES (or CAST), and - as
with DSA - we can make specific restrictions in order to meet
Yes. This is a natural fork. It is for people who want Suite B.
Which means the various USG organisations. Which before have not in
the past been that impressed with OpenPGP. Actually, not impressed
with anything in the open world, I'd say. We are really in new
territory now that the NSA/NIST people have opened their hearts and
declared Suite B.
Which isn't to say that we shouldn't consider compatibility, but to
say that this is a good, natural fork. We should also think about
(I would. I remember the pain that was PGP 5.)
I think we need to be careful here. Let's examine a use case.
I am a user of some RFC 4880 OpenPGP application. All algorithms are
available to me, e.g. I am not a government employee.
* I use the application to encrypt mail to 5 recipients, my friends.
They use RSA/DSA/ElGamal keys.
* I upgraded the application to the next version that happened to
implement "ECC in OpenPGP".
I assume that we agree that if I encrypt to exactly the same 5
people with new version, as far as algorithm selection is concerned,
the result is identical to the previous version.
* I added 6th recipient to the list, which uses ECDH key.
OK I see that. If...
I hope we will agree that it must be possible to send single e-mail
to 6 recipients. RFC 4880 specifies that the default encryption
algorithm is 3DES, thus, there is always a match. Why shouldn't
single e-mail be sent to 6 recipients with 3DES symmetric key?
Sorry, I don't agree. The RFC4880 specification is only for
applications that apply (more or less) to RFC4880!
Applications that implement both RFC4880 *and* OpenPGP/ECC/Suite B are
given no guarantee that this is likely to be seamless and joyful and
without any degradation in their promised user experience.
Just like S/MIME and RFC4880.
To imagine otherwise would be to say that RFC4880's promise is that
*all future work* is also compatible. That's hopeless. How far do we
want to take that promise? OpenPGP quantum key exchange? What
happens if the Russkies decide they want an OpenPGP GOST and they
decide it is incompatible by definition with OpenPGP ECC? Or, we can
retitle S/MIME as OpenPGP/S/Mime and insist on compatibility :)
My point: It is *not* a given that people using OpenPGP Suite B can
talk to people using RFC4880. Desirable, sure, but not a given.
(I'd bet the NSA would prefer this *not* to be the case ;)
Example: Consider properly written small-device platforms using the
ECC stuff: They will likely implement the AES128-ECC-SHA "small"
profile, and not include 3DES at all. The last thing anyone in the
smart card / mobile world wants is incompatibility forced by vestigial
circumstances. They want all *their* people talking, and that means
one system, one algorithm. Talking to other people is a distant
second in most business plans, and a controversial one at that.
If the application is operating in Suite-B mode, or FIPS more, etc,
then the situation is different.
Yes, there are security ramifications. Are we really implementing
Suite B if the application can leak info by sending out emails
encrypted in Suite B (strong) and in 3DES to some 512 RSA key (not so