1. SKS Keyserver
  2. SKS Keyserver
  3. sks-keyserver
  4. Issues
Issue #25 resolved

More ECC curves

Yutaka Niibe
created an issue

In the development branch of GnuPG, there are more curves supported (Brainpool P-256, P-384, and P-512, and secp256k1).

Could you consider supporting more curves (than defined in RFC6637)?

The function oid_to_psize in parsePGP.ml causes an error, currently.

For supported curves in GnuPG, please see: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=common/openpgp-oid.c;h=28567b7fec69e58ac8a20df1ebe4707ad225e4ef;hb=refs/heads/master#l266

Comments (24)

  1. Kristian Fiskerstrand

    Hi Yutaka.

    I would indeed prefer to see a new RFC (or an update to RFC6637) for this. In particular given the volatile state of GnuPG's ECC implementation at this time. I refer in particular to the commit mentioned below.

    Werner will talk about ECC on the GnuPG BOF at FOSDEM this weekend [0], will be very interesting to hear his plans.

    [0] http://lists.gnupg.org/pipermail/gnupg-users/2014-January/048892.html

    commit 59207a86e5f40c77fed296b642bf76692e8eef65 Author: Werner Koch wk@gnupg.org Date: Tue Oct 22 14:26:53 2013 +0200

    gpg: Change OID of Ed25519 and add Brainpool oids.

    * common/openpgp-oid.c (openpgp_curve_to_oid): Change OID for
    Ed25519.  Add brainpool OIDs.
    (openpgp_oid_to_curve): Ditto.
    This change is required to the change in Libgcrypt.  Note that we will
    likely use a different OpenPGP algorithm ID for EdDSA and thus the
    current Ed25519 implementation will not stay with us.
  2. Yutaka Niibe reporter

    Thank you for your response.

    I understand your point. Indeed, the support for Curve25519/Ed25519 is volatile. That's why I didn't address Curve25519/Ed25519 in my original message.

    For Curve25519/Ed25519, we need to extend other part of specification because its signature scheme is different (Ed25519 is for EdDSA != ECDSA).

    For curves of Brainpool P-256, P-384, and P-512, and secp256k1, it's just an addition to OID list. Well, I'm going to talk to the author of the RFC.

    If I could join FOSDEM this year...

  3. Kristian Fiskerstrand

    Could you provide the OIDs in hex format and a test key? If it is really just an addition of the OIDs to the list, and the format otherwise is the same we can probably be a bit more flexible, so with the requested information I can at least test it in my patch queue.

  4. Yutaka Niibe reporter

    Thank you very much. I have looked the patch and its OID list. IIUC, OID in the list is the one of DER encoding without tag. If so, I found no problem.

    I have submitted my two keys (one is real, another is just for testing) to your server. Both keys are RSA 2048-bit primary key with subkeys. Test key has brainpool subkeys and secp256k1 subkey. Real key only has secp256k1 subkey.

    When I extract key from the server, all ECC subkeys are removed.

    My real key is available at: gniibe.org

  5. Kristian Fiskerstrand

    This was probably my bad, the test server hadn't been restarted after applying the latest changes. sub 256E/975B9053 2014-01-16
    sig sbind 4CA7BABE 2014-01-16 _ _ [] shows up correctly for me on that server when checking now at least.

  6. Yutaka Niibe reporter

    Great. It's the subkey by secp256k1.

    It seems that it works with secp256k1, but I don't see subkeys of brainpool, which should be in a test key (primary key: 2048R/DA56415F).

  7. Kristian Fiskerstrand

    Seems there is some inconsistency in the OID, I added some more debugging and discovered that the OIDs has to be | "2403030208010107" -> 256 ( brainpoolP256r1 ) | "240303020801010b" -> 384 ( brainpoolP384r1 ) | "240303020801010d" -> 512 ( brainpoolP512r1 )

    for those subkeys to work, rather than -+ | "2b2403030208010107" -> 256 ( brainpoolP256r1 ) -+ | "2b240303020801010b" -> 384 ( brainpoolP384r1 ) -+ | "2b240303020801010d" -> 512 ( brainpoolP512r1 )

    as first used.. e.g. difference of leading "2b" . I'm not sure what is the right thing to use here for consistency (where a RFC would be helpful :p )

    sub 256E/FC7DD9B5 2014-02-03
    sig sbind DA56415F 2014-02-03 _ _ []

    sub 256E/76140390 2014-02-03
    sig sbind DA56415F 2014-02-03 _ _ []

    sub 384E/EEB57E7B 2014-02-03
    sig sbind DA56415F 2014-02-03 _ _ []

    sub 512E/E7FEB151 2014-02-03
    sig sbind DA56415F 2014-02-03 _ _ []

  8. Yutaka Niibe reporter

    I examined the three sub packets for these subkeys, and all look correct. For example, the subkey with brainpoolP256r1 is:

    Public Subkey Packet(tag 14)(83 bytes):
    52 ef 3f e0
       09 2b 24 03 03 02 08 01 01 07
       02 03
             58cd c920 a82b a2e3 22e7 dfd2 24b7 7b05
             5e79 2bb8 e9e9 ca69 1356 5f1f a720 be1c
             07c7 1c41 860a efd8 7aeb abef cf02 2388
             139f f77c 5925 f1c2 6300 ce89 c5b8 d749 

    I suspect that the routine getting OID. That is, the routine parse_ecdh_pubkey calls cin#read_int64_size. Here assumes that OID fits within 64-bit, I guess.

    Note that the OID representation is 9-byte for Brainpool*.

  9. Kristian Fiskerstrand

    Indeed, that is a good assessment. Now to ponder whether to do a two-step read with a bitshift into a BigInt or try to fix the channel reading. Immediately I'm more in favor of the former, but I'll have to think a bit about it.

  10. Kim Minh Kaplan

    What I mean is that all this idea of converting the data read to any other format, be it hexadecimal, BigInt or whatever, is a waste of work. Just use the data in the form you read it. Please re-read the patch I suggested.

  11. Log in to comment