Subject: [Dcrup] Hey, crypto experts, what signing algorithm should we add

From: "John Levine" <[email-masked]>
Date: 10 Jun 2017 12:55:45 -0000

The first goal here was to add an elliptical curve algorithm to DKIM
(and ARC.)  I'd like to get back to that.

Desiderata:

* Small keys that will fit in a TXT record

* Code widely available

* Signing and verification interfaces similar to RSA so the calling
code doesn't need to change much.

Any suggestions?

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Jun 2017 15:51:03 +0100

> Any suggestions?

I thought that you had already settled on Ed25519.  Availability is
the only concern of note based on your criteria.  We don't have it in
NSS (yet) and it's a bit green in some other libraries, but it's still
pretty widely available.

I see no huge motivation for Ed448 or ECDSA at this stage.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 Jun 2017 15:52:59 +0100

I think clearly either Ed25519 or ECDSA P-256. Either seems fine, with
ECDSA having an advantage on the availability and Ed25519 an advantage on
the modernness.

-Ekr

On Sat, Jun 10, 2017 at 3:51 PM, Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2017 12:07:37 -0400

> ECDSA having an advantage on the availability and Ed25519 an advantage on

Great.  How about the sign/verify interface compared to RSA ?  RSA has 
a length parameter but I gather that's in the blob of base64 key info.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 Jun 2017 17:08:18 +0100

On Sat, Jun 10, 2017 at 5:07 PM, John R Levine <[email-masked]> wrote:

> Great.  How about the sign/verify interface compared to RSA ?  RSA has a
> length parameter but I gather that's in the blob of base64 key info.
>

I'm not sure what you mean by a length parameter. Length of what?

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2017 12:11:35 -0400

> I'm not sure what you mean by a length parameter. Length of what?

The key.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Jun 2017 17:37:59 +0100

>> I'm not sure what you mean by a length parameter. Length of what?

Well, keys are fixed size, but you could include an argument if you
need to have a consistent API.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 10 Jun 2017 12:49:36 -0400

I think IETF is pretty much set on the 25519 approach.

Use RFC 8032, it is what it is for.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 Jun 2017 17:51:22 +0100

>> I'm not sure what you mean by a length parameter. Length of what?

Hmmm... That's not really part of the standard RSA signing interface that
I'm familiar with. See for instance [0].. Can you send me a pointer to what
you have in mind.

-Ekr

[0] https://wiki.openssl.org/index.php/Manual:RSA_sign(3)

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2017 13:48:28 -0400

> I'm familiar with. See for instance [0].. Can you send me a pointer to what

I do this to generate the key:

$ openssl genrsa -rand /dev/random -out key.example.com 1024

$ openssl rsa -in key.example.com -pubout | munge > key record

where munge removes the BEGIN/END PUBLIC KEY puts the key on one line

Somehow that blob includes the key length, since I can change the length 
and the signing and validation code is the same.

For the interface, it would be nice if the EC key were similarly 
self-describing.  Or it may be moot since the key sizes are fixed.

Regards,

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 10 Jun 2017 18:59:10 +0000

> and the signing and validation code is the same.

The encoding of an RSA key includes the key size.
 
> For the interface, it would be nice if the EC key were similarly self-describing.
> Or it may be moot since the key sizes are fixed.

Yes, the key sizes are fixed depending on the curve.  The encodings of curves are different and not self-describing.  If you see a string of bytes lying on the ground, you can't necessarily tell anything about the key -- if it is one, it's size, and which curve applies.  You need external state such as knowing the signing algorithm; that shouldn't be a problem.

Supporting Ed25519 will not come with zero code changes.  But minimal I think.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sat, 10 Jun 2017 12:16:01 -0700

For OpenSSL and ECDSA, the following example may help you:

$ openssl version
OpenSSL 1.0.2l  25 May 2017
$ : Tell OpenSSL what Elliptic Curve you want to use: prime256v1 in this case
$ openssl ecparam -out prime256v1-param.pem -name prime256v1
$ cat prime256v1-param.pem
-----BEGIN EC PARAMETERS-----
BggqhkjOPQMBBw==
-----END EC PARAMETERS-----
$ : Generate a private key based on the prime256v1
$ openssl ecparam -in prime256v1-param.pem -genkey -out my_privatekey.pem
$ cat my_privatekey.pem
-----BEGIN EC PARAMETERS-----
BggqhkjOPQMBBw==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIEwjT+3tXgsoPmQ4dGnVtAzuC03S7HHRiqPxifL0cE8UoAoGCCqGSM49
AwEHoUQDQgAEFTtSp6kPe2fjNNfHiaKGpMYFs19xnj6hTfpdmklxE1Y1ERP2Zlgj
2QG5vSbb13xbQ+EPcMdoLt4lBTpy+wxDQw==
-----END EC PRIVATE KEY-----
$ openssl ec -in my_privatekey.pem -noout -text
read EC key
Private-Key: (256 bit)
priv:
    4c:23:4f:ed:ed:5e:0b:28:3e:64:38:74:69:d5:b4:
    0c:ee:0b:4d:d2:ec:71:d1:8a:a3:f1:89:f2:f4:70:
    4f:14
pub:
    04:15:3b:52:a7:a9:0f:7b:67:e3:34:d7:c7:89:a2:
    86:a4:c6:05:b3:5f:71:9e:3e:a1:4d:fa:5d:9a:49:
    71:13:56:35:11:13:f6:66:58:23:d9:01:b9:bd:26:
    db:d7:7c:5b:43:e1:0f:70:c7:68:2e:de:25:05:3a:
    72:fb:0c:43:43
ASN1 OID: prime256v1
NIST CURVE: P-256
$ : Generate public key
$ openssl ec -in my_privatekey.pem -pubout -out my_publickey.pem
read EC key
writing EC key
$ cat my_publickey.pem
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFTtSp6kPe2fjNNfHiaKGpMYFs19x
nj6hTfpdmklxE1Y1ERP2Zlgj2QG5vSbb13xbQ+EPcMdoLt4lBTpy+wxDQw==
-----END PUBLIC KEY-----
$ 

If you look the PEM file contains the following prefix before the "pub:"
key

$ openssl ec -in my_privatekey.pem -pubout -out my_publickey.der -outform der
read EC key
writing EC key
$ od -t x1 my_publickey.der
0000000    30  59  30  13  06  07  2a  86  48  ce  3d  02  01  06  08  2a
0000020    86  48  ce  3d  03  01  07  03  42  00  04  15  3b  52  a7  a9
0000040    0f  7b  67  e3  34  d7  c7  89  a2  86  a4  c6  05  b3  5f  71
0000060    9e  3e  a1  4d  fa  5d  9a  49  71  13  56  35  11  13  f6  66
0000100    58  23  d9  01  b9  bd  26  db  d7  7c  5b  43  e1  0f  70  c7
0000120    68  2e  de  25  05  3a  72  fb  0c  43  43
$

Which decomposes to some front material:

    30:59:30:13:06:07:2a:86:48:ce:3d:02:01:06:08:2a:
    86:48:ce:3d:03:01:07:03:42:00:

followed by the public key:

    04:15:3b:52:a7:a9:0f:7b:67:e3:34:d7:c7:89:a2:
    86:a4:c6:05:b3:5f:71:9e:3e:a1:4d:fa:5d:9a:49:
    71:13:56:35:11:13:f6:66:58:23:d9:01:b9:bd:26:
    db:d7:7c:5b:43:e1:0f:70:c7:68:2e:de:25:05:3a:
    72:fb:0c:43:43

Use the key...

$ echo hello world > hello.txt
$ openssl dgst -sha256 -sign my_privatekey.pem hello.txt > hello.sig
$ openssl dgst -sha256 -verify my_publickey.pem -signature hello.sig hello.txt
Verified OK
$ od -t x1 hello.sig
0000000    30  45  02  20  55  5b  3c  3a  ab  2a  5f  70  de  62  a7  32
0000020    19  ea  e1  98  bb  13  1e  a7  00  9a  e4  52  ab  85  74  d8
0000040    c4  b0  4e  98  02  21  00  c0  aa  55  54  83  0f  54  33  f1
0000060    b4  53  fa  e9  f2  94  71  3c  5a  b7  83  a3  76  51  e1  24
0000100    84  d2  8c  41  dc  3d  5c
0000107
$ 

I suggest you not actually USE the public/private keypair provided above
given it is no longer secret.

      -- Mark

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2017 15:28:57 -0400

> Yes, the key sizes are fixed depending on the curve.  The encodings of 
> curves are different and not self-describing.  If you see a string of 
> bytes lying on the ground, you can't necessarily tell anything about the 
> key -- if it is one, it's size, and which curve applies.  You need 
> external state such as knowing the signing algorithm; that shouldn't be 
> a problem.

That's no problem, the DKIM key record has a field for the algorithm.

> Supporting Ed25519 will not come with zero code changes.  But minimal I think.

Since we have a lot of lazy programmers who will need to do this, how 
different is ED25519 sign/verify from RSA?

Regards,

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 10 Jun 2017 20:00:18 +0000

> That's no problem, the DKIM key record has a field for the algorithm.

Good.
  
> different is ED25519 sign/verify from RSA?

Rough estimate:  every time you do an RSA thing (load key, sign, etc) add an if test and six-10 additional lines.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Jun 2017 16:34:47 -0400

> different is ED25519 sign/verify from RSA?

For Python (I know, not everyone cares, but I do), PyNaCl offers a maintained 
and reasonably simple API for this:

https://pynacl.readthedocs.io/en/latest/signing/#example

As an implementer that would need to implement this, it seems eminently 
doable.  I'd prefer something supported in the Python standard library, but 
I'm certainly not holding my breath for it.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2017 22:21:43 -0400

> Rough estimate:  every time you do an RSA thing (load key, sign, etc) add an if test and six-10 additional lines.

If we want to add ED25519 as a new algorithm, can we just say that you use 
it where you would have used RSA, with standard base64 formats, and the 
discussions about key size don't apply?  Or do we need to say more?

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 11 Jun 2017 07:55:30 +0100

> where munge removes the BEGIN/END PUBLIC KEY puts the key on one line

Thanks for the explanation. That helps.

> self-describing.  Or it may be moot since the key sizes are fixed.

Yes the EC keys are self-describing. They say which curve they are on,
which tells you the length,
so you should be good.

Best
-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 11 Jun 2017 17:43:06 +0000

> If we want to add ED25519 as a new algorithm, can we just say that you use it
> where you would have used RSA, with standard base64 formats, and the

That should do it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Jun 2017 14:44:36 -0400

Which flavor of Ed25519?

Are we talking about RFC 8032 or something else. Because there really needs
to be a very very good reason not to use the standard as written.

The amount of code that needs to be writ is irrelevant to me. People will
have to write code whatever. It took me a day to write RFC8032. It will
take a lot longer to write a spec for anything else, do test vectors, etc.

---

From: "John R Levine" <[email-masked]>
Date: 11 Jun 2017 19:54:02 +0100

> to be a very very good reason not to use the standard as written.

I'm not aware of any reason to use anything other than RFC 8032.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Jun 2017 15:52:42 -0400

I just want to make sure we are clear on that.