[Top] [All Lists]

Re: I have a technical idea/change for the ECC draft

2008-04-15 06:00:06

A high level / managerial perspective. Apologies in advance for where it drifts from actual specifications.

We are deep down the rabbit hole known as

    _profiles v. algorithms_

It is worth standing back and thinking about this because when V5 keys are looked it, it is possible that we could solve this.

PGP was designed in the early 90s when algorithms were thought to be all there was to crypto. Now, we know that's wrong [1]. Now, we know it is all about applications and users, and they want communication before security, and security before crypto. From a crypto standpoint, profiles are the only way forward, because they remove interoperability issues, which improves communications.

But, still, today, OpenPGP prefers to indicate algorithms not profiles, so what to do?

1. Leave it entirely out of the ECC document and let the implementors discuss it. The problem with this is as highlighted by the Willmer/Laurie case. They apparently had to backtrack from their "cleanroom dox" implementation and go find info that was "shared" not written. So we are adding in an additional drag on the implementors.

That's fine if you believe that all implementors should talk anyway, but not so fine if some only talk in Chinese and others have poor social skills and good code is downloadable from sourceforge.

2. "legislative" position in the ECC document.  Something like:

   OpenPGP-ECC has no implied preference,
   and explicitly drops the TripleDES implied preference
   of RFC4880.  Each algorithm must be expressed.

   The existance of preferences AES-128 and AES-256 only
   MAY be taken as a signal that Suite-B is required.

Or somesuch. Plus side might be that it might mean less interop testing and less code. That would be a big win for ECC coders in the mobile field, as they could get a single tight profile.

Minus side might be that it might be ignored. Or, it might not, if we choose carefully. If it is ignored, we've lost nothing. If it is followed, then we've won.

3. "Security Notes / Comments" to the effect that the world has moved on and implementations should avoid using the old stuff. Something like:

  Although RFC4880 includes TripleDES as an obligatory
  and common algorithm, this algorithm is out of date.
  Implementors are likely to limit TripleDES to
  interoperability testing only, and application
  developers are likely to not offer TripleDES, or
  offer it under override conditions only.
  Implemetors should follow the profiles
  suggested in Suite-B.

This means that implementors still have to write TripleDES code and still have to interop test it. But application developers can ignore it.

4. Two Key flags to specify Suite-B (S + TS) as suggested by Andrey. This in effect adds profiles.

If we can do this for Suite-B, we can do it for RSA and other things. Consider a Suite-RSA "for the rest of us":

    Secret:     AES-128, RSA-3072, SHA256
    TopSecret:  AES-256, RSA-8192, SHA512

But this might be better off being left for V5?  Dunno.


[1] This is not a new mistake. Kherdkoffs wrote about it in 1883.