Mailing List Archive: GnuPG: devel

ECC code now in GnuPG master

Index | Next | Previous | View Threaded

wk at gnupg

Feb 3, 2011, 8:54 AM

Post #1 of 19 (952 views)
Permalink

ECC code now in GnuPG master

Hi,

after some cleanup Andrey's ECC code has been merged into GnuPG master
(aka 2.1). The latest commit also adds an extended algorithm selection
menu, which shows up like this:

$ ~/b/gnupg/g10/gpg2 --expert --gen-key
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(9) ECDSA and ECDH
(10) ECDSA (sign only)
(11) ECDSA (set your own capabilities)

Note that the --expert option is required to allow the generation of ECC
keys. When using the addkey sub-command of --edit-key, the list shows
up like this:

gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECDSA (sign only)
(11) ECDSA (set your own capabilities)
(12) ECDH (encrypt only)

Not ethat there are likely a couple of bugs left. A quick test shows
that 521 bit encryption keys can't be generated.

Please note that this ECC support is really new and shall not be used to
create production quality keys. A code audit is required and we also
need to do compliance testing with other implementations.

Remember to build and install the latest Libgcrypt master before
configuring GnuPG.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

calestyo at scientia

Feb 3, 2011, 10:27 AM

Post #2 of 19 (931 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

Hey...

Very nice :)

On Thu, 2011-02-03 at 17:54 +0100, Werner Koch wrote:
> after some cleanup Andrey's ECC code has been merged into GnuPG master
> (aka 2.1). The latest commit also adds an extended algorithm selection
> menu, which shows up like this:
So this is now already the "main" 2.1 tree or a copy of that one?

Do we have already any expectations when the ID goes RFC?

> Not ethat there are likely a couple of bugs left. A quick test shows
> that 521 bit encryption keys can't be generated.
What's the suggested keysizes,... and which are supported by gpg?

> Please note that this ECC support is really new and shall not be used to
> create production quality keys. A code audit is required and we also
> need to do compliance testing with other implementations.
Is there already an audit planned? Who will do it?

And are there any other implementations having ECC?

Is there a list of things which may not work (if any)?
E.g. things like, can you sign RSA/DSA keys with an ECC key, etc. pp.

Cheers,
Chris.

Attachments:

smime.p7s (5.54 KB)

dshaw at jabberwocky

Feb 3, 2011, 11:13 AM

Post #3 of 19 (934 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Feb 3, 2011, at 11:54 AM, Werner Koch wrote:

> Hi,
>
> after some cleanup Andrey's ECC code has been merged into GnuPG master
> (aka 2.1).

This is excellent! I'm very pleased to see it merged in. Congratulations to everyone involved.

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Feb 3, 2011, 12:16 PM

Post #4 of 19 (935 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Thu, 3 Feb 2011 19:27, calestyo [at] scientia said:

> So this is now already the "main" 2.1 tree or a copy of that one?

master; currently known as 2.1/

> Do we have already any expectations when the ID goes RFC?

No idea. However the (former) WG already accepted this draft. I guess
it is up to Andrey to proceed with the RFC process.

> What's the suggested keysizes,... and which are supported by gpg?

The default is 256, which uses the NIST P-256 curve. Other supported
curves are NIST P-384 and NIST P-521. We could also add other curves as
long as an OID is available and a user interface is written. However, I
believe that proliferation of curves is a bad idea. In contrast to RSA
key sizes, the application needs to know the curve parameters as they
are not part of the key.

> Is there already an audit planned? Who will do it?

I will for sure look over the code again but I was more thinking of an
independent audit.

> And are there any other implementations having ECC?

AFAICR, Andrey once wrote the support for the PGP SDK; I have no
information what happened to it at Symantec.

> Is there a list of things which may not work (if any)?
> E.g. things like, can you sign RSA/DSA keys with an ECC key, etc. pp.

It is part of OpenPGP and there are no restrictions except for the key
capabilities; i.e. like Elgamal you can't use ECDH for the primary key.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

calestyo at scientia

Feb 3, 2011, 12:33 PM

Post #5 of 19 (930 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Thu, 2011-02-03 at 21:16 +0100, Werner Koch wrote:
> > Is there already an audit planned? Who will do it?
>
> I will for sure look over the code again but I was more thinking of an
> independent audit.
The more the better =)

Anyway,... nice to see that things are moving forward with respect to
ecc....

Next thing is hopefully:
cat rfc4880.txt | sed s/sha-1/somethingBetter/

;)

Cheers,
Chris.

Attachments:

smime.p7s (5.54 KB)

John at enigmail

Feb 3, 2011, 12:57 PM

Post #6 of 19 (933 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

Werner Koch wrote:
> Hi,
>
> after some cleanup Andrey's ECC code has been merged into GnuPG master
> (aka 2.1).

Excellent! Congratulations to all involved for the hard work.

Are there plans to refactor the ECC code for inclusion into the 1.4 series?

--
John P. Clizbe Inet: John (a) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or
mailto:pgp-public-keys [at] gingerbear?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

Attachments:

signature.asc (0.87 KB)

wk at gnupg

Feb 3, 2011, 1:16 PM

Post #7 of 19 (933 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Thu, 3 Feb 2011 20:13, dshaw [at] jabberwocky said:

> This is excellent! I'm very pleased to see it merged in. Congratulations to everyone involved.

It turned out that in the end the required changes were not that big.

With that in mind I am toying with the idea of a GnuPG 1.5 to replace
1.4 with only one change: Replace the internal crypto code by Libgcrypt.
This has the advantage that we can take advantage of Libgcrypt
improvements automatically and don't need to backport delicate code.
The disadvantage is of course the extra dependency.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

calestyo at scientia

Feb 3, 2011, 1:28 PM

Post #8 of 19 (934 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Thu, 2011-02-03 at 22:16 +0100, Werner Koch wrote:
> With that in mind I am toying with the idea of a GnuPG 1.5 to replace
> 1.4 with only one change
Isn't it then a small step to ultimately drop the 1.x branch,... and
suggest people that don't like the dependencies to just compile gpg2
statically?
Perhaps allowing to drop the need for gpg-agent or so.

Are there any major platforms left where gpg builds, but gpg2 not?

Cheers,
Chris.

Attachments:

smime.p7s (5.54 KB)

dkg at fifthhorseman

Feb 3, 2011, 2:30 PM

Post #9 of 19 (931 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On 02/03/2011 04:16 PM, Werner Koch wrote:
> With that in mind I am toying with the idea of a GnuPG 1.5 to replace
> 1.4 with only one change: Replace the internal crypto code by Libgcrypt.
> This has the advantage that we can take advantage of Libgcrypt
> improvements automatically and don't need to backport delicate code.
> The disadvantage is of course the extra dependency.

I quite like this idea. fwiw, debian just moved gcrypt from /usr/lib
into /lib, so that it can be used as a dependency for critical code
during boot (and during recovery when /usr isn't mounted.

So i'm not concerned about the extra dependency for debian, anyway.

I also want to add my voice to the chorus of folks saying "good work!"
I'm happy to see this get merged.

Regards,

--dkg

Attachments:

signature.asc (1.01 KB)

dshaw at jabberwocky

Feb 3, 2011, 2:38 PM

Post #10 of 19 (936 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Feb 3, 2011, at 4:16 PM, Werner Koch wrote:

> On Thu, 3 Feb 2011 20:13, dshaw [at] jabberwocky said:
>
>> This is excellent! I'm very pleased to see it merged in. Congratulations to everyone involved.
>
> It turned out that in the end the required changes were not that big.
>
> With that in mind I am toying with the idea of a GnuPG 1.5 to replace
> 1.4 with only one change: Replace the internal crypto code by Libgcrypt.
> This has the advantage that we can take advantage of Libgcrypt
> improvements automatically and don't need to backport delicate code.
> The disadvantage is of course the extra dependency.

I like this idea, but since we're talking about adding an extra dependency anyway, I wonder if it might be a better direction, rather than add libgcrypt to GnuPG 1.4, to instead make a "mini" version of GnuPG 2.x for server use (leaving out the non-OpenPGP stuff, the agent, etc). A long while ago, you and I talked about that sort of compile-time possibility.

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

avi.wiki at gmail

Feb 3, 2011, 2:46 PM

Post #11 of 19 (930 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

That is great news, Werner. Now, for those of us who are
absolutely incapable of compiling code, let alone knowing what
gcc is and linking libraries, AND who live in the evil Windows
empire, will a binary ever be released that contains ECC
support? In a similar vein, for those of us who like the small
size and independence of the 1.x trunk (I keep an minimal
installation of GnuPG, GPGShell, and my keyrings on a truecrypt
encrypted folder on my usb stick), are there plans for ECC to be
brought into the 1.X trunk, or will n00bz like me have to hope
that someone compiles a stand-alone version of 2.1 for our use?

Thank you,

- --Avi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32) - GPGshell v3.77
Comment: Most recent key: Click show in box @ http://is.gd/4xJrs

iJgEAREKAEAFAk1LMD85GGh0dHA6Ly9wZ3AubmljLmFkLmpwL3Brcy9sb29rdXA/
b3A9Z2V0JnNlYXJjaD0weEY4MEUyOUY5AAoJEA1isBn4Din5DfMBAI0xH/51olFL
6qDY6DDEvlE57tWradQacAQsxsx4xXUYAPwNDOKF9yXXtIo7XIG1djnwCahRDrkt
lk5Bz4HOoJi2Qw==
=33/j
-----END PGP SIGNATURE-----

----
User:Avraham

pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) <avi.wiki [at] gmail
>
Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E
29F9

smujohnson at gmail

Feb 3, 2011, 6:46 PM

Post #12 of 19 (929 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

Glad you asked, I'm sort of in the same boat. I am a win32 kinda-guy and
hate compiling stuff bigger than a hello world program. I just use the
installers with GnuPG v1.xx.x stuff, and this new v2 branch sounds pretty
cool.

On Thu, Feb 3, 2011 at 2:46 PM, Avi <avi.wiki [at] gmail> wrote:

> That is great news, Werner. Now, for those of us who are
> absolutely incapable of compiling code, let alone knowing what
> gcc is and linking libraries, AND who live in the evil Windows
> empire, will a binary ever be released that contains ECC
> support? In a similar vein, for those of us who like the small
> size and independence of the 1.x trunk (I keep an minimal
> installation of GnuPG, GPGShell, and my keyrings on a truecrypt
> encrypted folder on my usb stick), are there plans for ECC to be
> brought into the 1.X trunk, or will n00bz like me have to hope
> that someone compiles a stand-alone version of 2.1 for our use?
>
> Thank you,
>
> - --Avi
>

wk at gnupg

Feb 3, 2011, 9:36 PM

Post #13 of 19 (926 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Thu, 3 Feb 2011 23:38, dshaw [at] jabberwocky said:

> than add libgcrypt to GnuPG 1.4, to instead make a "mini" version of
> GnuPG 2.x for server use (leaving out the non-OpenPGP stuff, the
> agent, etc). A long while ago, you and I talked about that sort of
> compile-time possibility.

I can't remember the details of the discussion anymore. The major
hurdle is that we need to write a new agent which does not assume to run
in an interactive environment. The functionality of the agent (secret
key operation) is obviously required.

We may link such new agent code into gpg proper, much like we do with
the smartcard code in 1.4. Another, simpler, option would be to keep
the agent but make it loop back to gpg to ask for the passphrase.
Recall that the agent is now reliable started on demand on a per
GNUPGHOME base.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

sergi at calcurco

Feb 4, 2011, 12:55 AM

Post #14 of 19 (917 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Thu, Feb 3, 2011 at 9:16 PM, Werner Koch <wk [at] gnupg> wrote:
> On Thu, �3 Feb 2011 19:27, calestyo [at] scientia said:
>> What's the suggested keysizes,... and which are supported by gpg?
>
> The default is 256, which uses the NIST P-256 curve. �Other supported
> curves are NIST P-384 and NIST P-521. �We could also add other curves as
> long as an OID is available and a user interface is written. �However, I
> believe that proliferation of curves is a bad idea. �In contrast to RSA
> key sizes, the application needs to know the curve parameters as they
> are not part of the key.

IMHO, the proliferation of curves is a feature of the ecc. The
X9.62-1998 (section 5.1) evaluates as a security risk the multiple
users sharing of the same elliptic curve domain parameters. An
probably they has not thinking that this can be three curves for all
the users.

With ecc you have the feature to change the cyclic subgroup (change
'a', 'b') without increase the size of the base field. Over prime
finite fields the unique option you have is to increase the size of
'p'.

I understand the bigger issue that this proliferation can make. But,
step by step, some day this is a feature that will be need.
Cryptography programming must be like satellite navigation
programming, the cost of a mistake is huge!

/Sergi.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

squalyl at gmail

Feb 4, 2011, 2:45 AM

Post #15 of 19 (922 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

the proliferation of curves is a barrier to interoperability,
specially with smart cards.
</rant>
apart from that ECC is a very nice PK scheme.

Sebastien

On Fri, Feb 4, 2011 at 9:55 AM, Sergi Blanch i Torné <sergi [at] calcurco> wrote:
> On Thu, Feb 3, 2011 at 9:16 PM, Werner Koch <wk [at] gnupg> wrote:
>> On Thu, 3 Feb 2011 19:27, calestyo [at] scientia said:
>>> What's the suggested keysizes,... and which are supported by gpg?
>>
>> The default is 256, which uses the NIST P-256 curve. Other supported
>> curves are NIST P-384 and NIST P-521. We could also add other curves as
>> long as an OID is available and a user interface is written. However, I
>> believe that proliferation of curves is a bad idea. In contrast to RSA
>> key sizes, the application needs to know the curve parameters as they
>> are not part of the key.
>
> IMHO, the proliferation of curves is a feature of the ecc. The
> X9.62-1998 (section 5.1) evaluates as a security risk the multiple
> users sharing of the same elliptic curve domain parameters. An
> probably they has not thinking that this can be three curves for all
> the users.
>
> With ecc you have the feature to change the cyclic subgroup (change
> 'a', 'b') without increase the size of the base field. Over prime
> finite fields the unique option you have is to increase the size of
> 'p'.
>
> I understand the bigger issue that this proliferation can make. But,
> step by step, some day this is a feature that will be need.
> Cryptography programming must be like satellite navigation
> programming, the cost of a mistake is huge!
>
> /Sergi.
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

sergi at calcurco

Feb 4, 2011, 4:20 AM

Post #16 of 19 (916 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

I understand this, but I feel it as a barrier to surpass. The
mathematical methods to operate ec points in libgcrypt, has been
programmed in the generic way that the P1363 says. They should work
with other curves, and they had not problem with the brainpool curves.

Not tomorrow, neither the day after, but I think is good to have on
mind the possibility to work on the direction to have this elliptic
curve feature available. Specially for the smart cards, due to an
attack to an specific elliptic curve can be aborted changing the curve
without affect the design of the card for one length to a bigger one.

Also, against side channel attack, it's proposed to use isogenies to
avoid zero-value points. And this means that the implementation must
work fine with more curves than a few selected.

/Sergi.

On Fri, Feb 4, 2011 at 11:45 AM, S�bastien Lorquet <squalyl [at] gmail> wrote:
> the proliferation of curves is a barrier to interoperability,
> specially with smart cards.
> </rant>
> apart from that ECC is a very nice PK scheme.
>
> Sebastien
>
> On Fri, Feb 4, 2011 at 9:55 AM, Sergi Blanch i Torn� <sergi [at] calcurco> wrote:
>> On Thu, Feb 3, 2011 at 9:16 PM, Werner Koch <wk [at] gnupg> wrote:
>>> On Thu, �3 Feb 2011 19:27, calestyo [at] scientia said:
>>>> What's the suggested keysizes,... and which are supported by gpg?
>>>
>>> The default is 256, which uses the NIST P-256 curve. �Other supported
>>> curves are NIST P-384 and NIST P-521. �We could also add other curves as
>>> long as an OID is available and a user interface is written. �However, I
>>> believe that proliferation of curves is a bad idea. �In contrast to RSA
>>> key sizes, the application needs to know the curve parameters as they
>>> are not part of the key.
>>
>> IMHO, the proliferation of curves is a feature of the ecc. The
>> X9.62-1998 (section 5.1) evaluates as a security risk the multiple
>> users sharing of the same elliptic curve domain parameters. An
>> probably they has not thinking that this can be three curves for all
>> the users.
>>
>> With ecc you have the feature to change the cyclic subgroup (change
>> 'a', 'b') without increase the size of the base field. Over prime
>> finite fields the unique option you have is to increase the size of
>> 'p'.
>>
>> I understand the bigger issue that this proliferation can make. But,
>> step by step, some day this is a feature that will be need.
>> Cryptography programming must be like satellite navigation
>> programming, the cost of a mistake is huge!
>>
>> /Sergi.
>>
>> _______________________________________________
>> Gnupg-devel mailing list
>> Gnupg-devel [at] gnupg
>> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>>
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Feb 4, 2011, 7:32 AM

Post #17 of 19 (910 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Fri, 4 Feb 2011 11:45, squalyl [at] gmail said:
> the proliferation of curves is a barrier to interoperability,

Right. It doesn't help if everyone uses custom curves but most won't be
able to encrypt messages to that key. There is also the question of
parameter validation.

I guess we will add a few more curves if there is a real demand for it,
but this should be limited to what is really needed. Frankly, I was one
of those who favored an OID approach instead of just a simple number to
describe the curve. This is the OpenPGP feature which allows us to
extend ECC. It is more like all the algorithm ids we have, we need to
limit them and add a new algorithm only for a real (political) reason,
like Camellia.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

nicholas.cole at gmail

Feb 4, 2011, 8:07 AM

Post #18 of 19 (913 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Thu, Feb 3, 2011 at 4:54 PM, Werner Koch <wk [at] gnupg> wrote:
> Hi,
>
> after some cleanup Andrey's ECC code has been merged into GnuPG master
> (aka 2.1). �The latest commit also adds an extended algorithm selection
> menu, which shows up like this:
>
> �$ ~/b/gnupg/g10/gpg2 --expert --gen-key
> �Please select what kind of key you want:
> � � (1) RSA and RSA (default)
> � � (2) DSA and Elgamal
> � � (3) DSA (sign only)
> � � (4) RSA (sign only)
> � � (7) DSA (set your own capabilities)
> � � (8) RSA (set your own capabilities)
> � � (9) ECDSA and ECDH
> � �(10) ECDSA (sign only)
> � �(11) ECDSA (set your own capabilities)

Will you also be adding EC support to the batch generation system?

Best wishes,

Nicholas

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Feb 6, 2011, 4:09 AM

Post #19 of 19 (908 views)
Permalink

Re: ECC code now in GnuPG master [In reply to]

On Fri, 4 Feb 2011 17:07, nicholas.cole [at] gmail said:

> Will you also be adding EC support to the batch generation system?

Is already availabale. Let me know if there is a problem. I need to
add a couple of regression tests; which also requires the batch
interface.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads