Re: ECC in OpenPGP proposal
2008-03-04 09:23:14
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 3DES
symmetric encryption, SHA1 digest and ZLIB compression must remain open until
a formal process of phasing them out is initiated, with a clear road map.
Right now, excluding these algorithms would break interoperability in a very
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
compliance.
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 taking it...
(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 strong)?
iang
|
|