headers
Andrey Jivsov | 19 Feb 2008 05:00

ECC in OpenPGP proposal


Hello OpenPGP list,

as Hal Finney had mentioned earlier, here is the draft:
    http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt

Unless you read this on a text terminal, here is the document in 
alternative formats that offer cross-references as navigation links:
    http://brainhub.googlepages.com/pgp

This submissions considers comments of the group to earlier Elliptic 
curve Cryptography (ECC) draft submissions. A couple of issues that were 
raised then are the justification for ECC in OpenPGP and how the larger 
set of ECC parameters can be managed.

Why do we need ECC? The main reason is better alignment with the 
strength of symmetric key. Given that US government has chosen ECC in 
favor of modp for larger key sizes, this proposal is carefully written 
to comply with NSA Suite-B. Informally, this is a proposal for these who 
are concerned that the use of SHA2-512 and AES-256 will need something 
stronger that RSA 1024. By optimistic estimates users should use at 
least RSA 4096 with AES 256, while it is a common assumption that RSA 
8192 is more appropriate. In practice, many sites today are not able to 
use RSA keys of sizes greater than 4096. ECC offers alternatives to 
larger modp key sizes. Another advantage of ECC is an opportunity to 
expand the set of hardware on which OpenPGP can be implemented. The 
security of AES-128 with corresponding ECC public key may be more 
attractive for "weak" devices, as opposed to RSA public keys, especially 
because the ECC curves introduced by this standard are already supported 
by TLS, IKE, PKIX, and SSH. Any system that communicates over slow
(Continue reading)

Permalink | Reply | 9 comments |
headers
Ian G | 20 Feb 2008 11:12

Re: ECC in OpenPGP proposal


Hi all,

Some comments.  Caveat:  I wouldn't know an EC if someone 
hit me over the head with it...

Big comment:  far too much variability, for little gain.

Andrey Jivsov wrote:
> 
> Hello OpenPGP list,
> 
> as Hal Finney had mentioned earlier, here is the draft:
>    http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt
> 
> Unless you read this on a text terminal, here is the document in 
> alternative formats that offer cross-references as navigation links:
>    http://brainhub.googlepages.com/pgp

> Why do we need ECC? The main reason is better alignment with the 
> strength of symmetric key. Given that US government has chosen ECC in 
> favor of modp for larger key sizes, this proposal is carefully written 
> to comply with NSA Suite-B.

I think it is sufficient to state that you want a Suite-B 
compatible profile.

4.  ... "SHOULD support ECDH"

what is the point of not supporting ECDH?  I recommend MUST.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Andrey Jivsov | 21 Feb 2008 09:08

Re: ECC in OpenPGP proposal


Hello Ian, thank you for your comments.

Ian G wrote:
>
> Hi all,
>
>
> Some comments.  Caveat:  I wouldn't know an EC if someone hit me over 
> the head with it...
>
> Big comment:  far too much variability, for little gain.
>
>
>
>
>
>
> Andrey Jivsov wrote:
>>
>> Hello OpenPGP list,
>>
>> as Hal Finney had mentioned earlier, here is the draft:
>>    http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt
>>
>> Unless you read this on a text terminal, here is the document in 
>> alternative formats that offer cross-references as navigation links:
>>    http://brainhub.googlepages.com/pgp
>
>> Why do we need ECC? The main reason is better alignment with the
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ian G | 21 Feb 2008 12:45

Re: ECC in OpenPGP proposal


Andrey Jivsov wrote:
> Hello Ian, thank you for your comments.

Thanks for response.  I have not responded in detail to all 
your responses, we might be better off both seeing how the 
rest of the group chimes in.  Instead I've just amplified my 
points where there was some divergence.

On background, when it comes to agility, I am a little bit 
of a nazi.  To me, choice is bad, nasty, evil.  This is 
because the choice does no good for the user, and lots and 
lots of bad.

http://iang.org/ssl/h1_the_one_true_cipher_suite.html

A few points below:

>>   ... "SHOULD support ECDH"
>>
>> what is the point of not supporting ECDH?  I recommend MUST.
>>
> 
> I can support this.
> 
> However, please note that the signature has more weight by being a tool 
> of certifications, i.e. self-signatures depends on it. Without support 
> for ECDSA we cannot have functional EC keys, while we can have sign-only 
> keys without ECDH. It is possible to have sign+encrypt keys with ECDSA 
> top key and modp ElGamal DH.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Andrey Jivsov | 23 Feb 2008 07:12

Re: ECC in OpenPGP proposal


Hello Ian,

I appreciate your pragmatism regarding algorithm agility. There are two 
practical issues we need to worry about: steady increase in processing 
power and the difference in processing power on various hardware.

A proposal with single ciphersuite cannot remain adequate indefinitely. 
We need ability to roll forward the strength of public key crypto as 
yesterday's strength declines over time.

We have impressive breadth of hardware that supports ECC today: from 
servers to smartcards. These devices demand some breadth of choices for 
ECC curves: servers might want the ultimate crypto strength, while 
smartcards are usually trying to meet set manufacturing cost at OK 
performance.

The document we discuss has three "ciphersuites" with two of them as 
MUST. As I said, I am OK with making only one MUST. I am inclined toward 
weaker one, since it has to be the lowest common denominator.
Permalink | Reply | 0 comments |
headers
Nikos Mavrogiannopoulos | 25 Feb 2008 22:33

updated TLS-Openpgp protocol


I've updated the experimental protocol for openpgp keys. The updated 
version can be found at:
http://www.ietf.org/internet-drafts/draft-mavrogiannopoulos-rfc5081bis-00.txt

The main addition is that it adds support for using subkeys instead of 
the main key of the openpgp certificate. For this reason i'd like to 
revive this protocol as a TLS WG item. For this to be possible there 
must be interest on this protocol, so if there are there people in this 
list supporting this protocol please express it.

Of course comments are always welcome.

regards,
Nikos

PS. Currently there is a module for the apache web server implementing 
the openpgp-tls protocol, available at: 
http://www.outoforder.cc/projects/apache/mod_gnutls/
Permalink | Reply | 0 comments |
headers
Jon Callas | 26 Feb 2008 21:59
Gravatar

Re: ECC in OpenPGP proposal


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

On Feb 21, 2008, at 3:45 AM, Ian G wrote:

>
> Andrey Jivsov wrote:
>> Hello Ian, thank you for your comments.
>
>
> Thanks for response.  I have not responded in detail to all your  
> responses, we might be better off both seeing how the rest of the  
> group chimes in.  Instead I've just amplified my points where there  
> was some divergence.
>
> On background, when it comes to agility, I am a little bit of a  
> nazi.  To me, choice is bad, nasty, evil.  This is because the  
> choice does no good for the user, and lots and lots of bad.
>
> http://iang.org/ssl/h1_the_one_true_cipher_suite.html

Ian,

I agree that there is virtue in limiting choice. However, there are a  
lot of people who want ECC, particularly in the context of Suite B. In  
the not-to-distant future, this will be a requirement.

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ian G | 27 Feb 2008 11:50

Re: ECC in OpenPGP proposal


Hi Jon,

Jon Callas wrote:

>> http://iang.org/ssl/h1_the_one_true_cipher_suite.html
> 
> Ian,
> 
> I agree that there is virtue in limiting choice. However, there are a  
> lot of people who want ECC, particularly in the context of Suite B. In  
> the not-to-distant future, this will be a requirement.

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.)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Werner Koch | 27 Feb 2008 16:51
Picon
Favicon

ECC curve ID


Hi,

altough I am aware of the discussion about limiting the number of
algorithms/profiles in a future ECC option, I am not happy with section
10 of the draft:

  10. ECC curve ID

   The parameter ECC curve ID is an integer that defines the named
   curve.

       ID      Curve description                      Curve name
        0      Reserved
        1      NIST Curve P-256 [FIPS 186-2]          "NIST P256"
        2      NIST Curve P-384 [FIPS 186-2]          "NIST P384"
        3      NIST Curve P-521 [FIPS 186-2]          "NIST P521"
     100-110   Private/Experimental curves
       255     Reserved for future expansion

Although this uses the same scheme we use all over OpenPGP, we should
make future life easier for all by not using registered IDs but use
other identifiers here.  For registering IDs we need to informal agree
on a new identifier, implement that one and then wait a couple of
months/years until it gets really assigned.  The private/experimental
IDs are not really useful for this because they can't be used after the
algorithm has been offically registered.

Thus, I propose to use ASN.1 object identifiers for the curves; i.e.:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Mike Markowitz | 27 Feb 2008 19:54

Re: ECC curve ID


At 09:51 AM 2/27/2008, Werner Koch wrote:
>     1.2.840.10045.3.1.7  NIST P-256   (Not sure about this OID)

Werner: We think that this is correct -- at least it's what we've been using
for quite some time and have received no complaints to date (and have witnessed
no conflicts between our code and everything we've been able to access for
compatibility testing).

Microsoft agrees (and our P-256 ECC certs are accepted by Vista IE):
   "XCN_OID_ECC_CURVE_P256 (1.2.840.10045.3.1.7) "
http://msdn2.microsoft.com/en-us/library/aa379070(VS.85).aspx

Also, if you need an official NIST reference, SP 800-78-1 lists this OID on
page 9 (table 3-6):
   http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf

In hex, it's "0x2A8648CE3D030107."

Cheers,
Michael

==========
Michael J. Markowitz, Ph.D.        Email: markowitz <at> infoseccorp.com
Vice President R&D                 Voice: 708-445-1704 (Oak Park)
Information Security Corporation          847-405-0500 (Deerfield)
1011 Lake Street, Suite 425        Fax:   708-445-9705
Oak Park, IL  60301                WWW:   http://www.infoseccorp.com
(Continue reading)

Permalink | Reply | 0 comments |

Gmane