On 3/4/08, Ian G <iang(_at_)systemics(_dot_)com> wrote:
OK, I think I found it. Sorry for not keeping up!
no problem.
Also, note that yours and my emails have overlapped in
our composing/sending, and that I unintentionally sent
me last email to just you rather than the list.
Hopefully everyone can now re-follow the discussion!
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 :)
yes, I have also disagreed - and still do "in principle".
*However,* I can (now) accept that as a "way forward"
compromise we can have both ECC and some interoperability
with current OpenPGP.
I'm attempting to (subtly ;) ) try and implement wording for
us that similarly "encourages" use of AES over 3DES by having
an "implementations SHOULD try and match sym & pk key
lengths" bit, together if possible (help me here Ian ;) ) with a
further "longer lengths should be preferred".
Maybe we should even add an example:
If Alice has a 1024 bit RSA key and Bob a 521-bit ECC key,
and both Alice and Bob have AES256 as one of their
possible cipher preferences, then implementations SHOULD
choose this stronger cipher.
This is a hack on 4880's "implementations may choose any
method of selecting from the intersection of preferences" -
i.e., for ECC we are saying how implementations SHOULD
(but, note, not any stronger than SHOULD). I feel this is both
within the spirit of 4880 *as well as* our best intentions to
encourage AES.
> 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.
But it has been pointed out that we can still keep 4880 compliance
by inheriting its 3DES (and then "encouraging" AES when used with
Ecc).
It is for people who want
Suite B.
I think there are "people who want *ECC*" and *also* people
who want Suite B.
Personally, I'd like to *only* see Suite B ECC, but consider
people thinking "hey, OpenPGP only has 384-bit ECC, but
<other product/standard> has 521-bit. OpenPGP sucks!"
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.
yes, we certainly are.
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.)
We could "force" a split, *or*, we could orchestrate a slow
migration, through adding ECC ("hey, cool, PGP has a new
public key algorithm. It must be better!"), and then perhaps
with V5 keys.
>> 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.
we're now saying there's a way.
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.
Then they're not OpenPGP/4880 compliant/compatible/
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.
That one algorithm *at present* is 3DES.
>> 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)?
Going forward we need to re-establish what is considered
minimally secure.
With ECC we're effectively closing off SHA1 (as a hash; it'll
still be there for, e.g., the fingerprint, at least as I understand it).
With V5 keys we could vape SHA1 entirely, and set 2048 (IF/DLP)
/ 256 (ECC) public keys as the minimum lengths.
2030 is our next "target" - that will likely mark the point when we
need to shift from 3DES, SHA224 and 2048IFDLP/224ECC to (for
the lowest strength) SHA256-AES128-3072IFDLP/256ECC.
iang