Re: ECC in OpenPGP proposal

[Jon Callas <jon@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> For the record, I agree there should be a Suite B !  It is an  
> economic reality, a real-world requirement.  When NIST/NSA speaks,  
> that's it.
>
> The short summary of my argument is that there should one and only  
> one MUST profile for Suite B, and that it should be the strong one /  
> Top Secret.
>
> Other lesser profiles could be MAY, or if you let the agility nazis  
> have their way, absent, as they have no economic use and lots and  
> lots of costs to users.
>
> (The reason I say that 'Secret' could be a MAY is that there are  
> complicated blah blahs in the government/security world that  
> sometimes force suppliers to provide several modes, against good  
> security practice.)
>
> (I'm aware of the "mobile" argument that was raised in the previous  
> post.  I would say that the mobile boys propose a "mobile" profile.   
> That's because mobile has other aspects that aren't necessarily  
> considered in Suite B.)

Excellent.

For a number of reasons, ECC/Suite B is going to be a MAY. You will be  
permitted to make an OpenPGP application that doesn't do it.

(Presently, our MUST algorithms are DSA, Elgamal, 3DES, and SHA1.  
Changing MUSTs is a can of worms and I don't think any IETF standard  
is handling it well.)

Like many things coming out of NIST, they come in three flavors, 128- 
bit security, 192-bit, and 256-bit. I have no objection myself to  
canning the 192-bit ones. I'm of the opinion that if you need more  
than 128, you should go to 256. In many cases, there isn't even a  
performance win on the 192-bit system.

However, there are very good arguments for doing 192-bit as well, and  
one of those arguments is that it may be easier to do the 192-bit  
versions than to explain why you didn't.

I don't see how we can simplify past dropping 192.


>
>
>
>> There are also other changes we will need to do on the horizon.  
>> For  example, someday there will be an AHS hash algorithm set from  
>> NIST. Do  we not to that, either? The argument you give is to have  
>> no choices.
>
>
> Yes.  AHS is years away, if AES was any guide.  AHS won't improve  
> overall security markedly over SHA256-512 family. NIST/NSA will also  
> have to update Suite B when AHS comes out.
>
> When all that dust settles, then is the time to reconsider it.  I  
> would plan on Suite B (one profile) now and know that in 5 or 7  
> years we will need to do a Suite B-bis.

The NIST schedule has a decision made in 2012. The submissions must be  
made this August.

>
>
>
>> For the people who want more, is to use S/MIME? If so, and if  
>> that's  the decision of the working group -- well, I disagree, but  
>> rough  consensus is rough consensus. My company does both OpenPGP  
>> and S/MIME.  If the answer to people who want Suite B is that we  
>> support it with S/ MIME, that's fine. It is also a huge  
>> disappointment, because I would  like to satisfy people's ECC and  
>> Suite B needs with OpenPGP, but we  can always migrate people to S/ 
>> MIME who need that.
>
>
> I think there should be a Suite B, in OpenPGP.
>
> And, to forestall the outrage, I fully expect to not get consensus  
> on my plea to reduce agility :)  We waited for 10 years to get the  
> current OpenPGP draft, so we can wait another 10 years to find out  
> why it took 10 years...

Cool.

	Jon



-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFHxeXKsTedWZOD3gYRAnhSAJ92jiokj+2HJdnY03yFT2t9O5PYIwCgiJBo
0pREjuhus2l54lTJL14DeIU=
=Zlos
-----END PGP SIGNATURE-----