[Top] [All Lists]

Re: ECC in OpenPGP proposal

2008-02-29 02:36:23

Hash: SHA1

On Feb 28, 2008, at 11:02 AM, David Crick wrote:

Ian wrote:

Hmmm... you raise an interesting point. I had thought that this
was going to be a new document, and as it is not referred to in
the existing core RFC, then ECC/Suite B was going to be a MAY by

Within that new (MAY) document, there would be several choices
for MUST, SHOULD, MAY, etc.

Or so I thought ... but I'm not fully aware of how these things  

and further:

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

OK, if you are happy to carry on this discussion ... what are the
reasons for including the 128-bit profile?

assuming the may -> whatever chain above holds, what about:

MAY implement ECC
 o MUST implement AES256-SHA384-384ECC
 o SHOULD implement AES128-SHA256-256ECC
 o MAY implement AES256-SHA512-521ECC
   [and/or any other combinations, but these might be "unbalanced"]

I think you have the polarity wrong.

AES256-SHA512-521ECC is desirable because it's the most secure.

AES128-SHA256-256ECC is desirable because it's fast, and it's what is  
most likely to be in constrained environments.

AES256-SHA384-384ECC (which I think should actually be AES192- 
SHA384-384ECC), is slow and not as secure. It's neither fish nor fowl.

However, for completeness, eliminating it is likely not wise. As much  
as I sneer at NIST's fondness for 192-bit security (especially when it  
runs at the same speed as 256-bit security), it's foolish to eliminate  
it from the spec. That's the sort of thing that might bite us in the  
ass years from now. The probability that I'll get a cogent,  
enlightening explanation of why 192-bit security is a Good Thing is  
directly proportional to the probability of our excluding it.


Version: PGP Universal 2.6.3
Charset: US-ASCII


<Prev in Thread] Current Thread [Next in Thread>