Subject: [jose] JWS algorithms: DSA, non-NIST curves

From: Dirkjan Ochtman <[email-masked]>
Date: Tue, 12 Nov 2013 14:07:26 +0100

Hi there,

In Persona/BrowserID, we're currently using DSA signatures (using a
"DS128" value for "alg"). Would it be possible to get this into the
current JWS/JWA drafts? We're currently looking at upgrading our
formats to current JOSE draft, see here:

https://github.com/djc/id-specs/blob/prod/browserid/json-formats.md

Relatedly, I was wondering if there's been discussion on including any
non-NIST curves in JWA. With recent developments, it appears that the
NIST curves may be a little suspect.

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf

Instead, some of Bernstein et al.'s SafeCurves could be added:

http://safecurves.cr.yp.to/

In particular, algorithms based on the 25519 curve already seems to be
in fairly widespread use.

Cheers,

Dirkjan

---

From: Daniel Holth <[email-masked]>
Date: Tue, 12 Nov 2013 08:27:27 -0500

I have been using ed25519 with JWS and have found it to be very
convenient. I use "Ed25519" as the alg and call the public and private
parts of the key "vk" and "sk" (verifying and signing key)
respectively. The compact key and signature size, fast signature
verification, and very fast key generation and signing are attractive.

On Tue, Nov 12, 2013 at 8:07 AM, Dirkjan Ochtman <[email-masked]> wrote:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Nov 2013 19:01:57 +0000

Anyone will be able to register algorithm identifiers in the algorithms registry, with the only requirement being that a document is written that specifies the algorithm behavior.  So you could define DS128, etc. and register them if you choose.

Mainly because I'm interested, can you give the working group some background on why you decided to use DSA?

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirkjan Ochtman
Sent: Tuesday, November 12, 2013 5:07 AM
To: [email-masked]
Subject: [jose] JWS algorithms: DSA, non-NIST curves

Hi there,

In Persona/BrowserID, we're currently using DSA signatures (using a "DS128" value for "alg"). Would it be possible to get this into the current JWS/JWA drafts? We're currently looking at upgrading our formats to current JOSE draft, see here:

Relatedly, I was wondering if there's been discussion on including any non-NIST curves in JWA. With recent developments, it appears that the NIST curves may be a little suspect.

In particular, algorithms based on the 25519 curve already seems to be in fairly widespread use.

Cheers,

Dirkjan

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Nov 2013 11:54:51 -0800

We have alg for ECDSA with the NIST curves P-256, P 384 and P-521.

Are you wanting Specifically Bernstein's 25519 curve or some more general curve agility?

We restricted the curves initially in favour of getting interoperability as opposed to using arbitrary curves.

It may be best to look to the CFRG for advice on specific curves.   JOSE is mostly about the serialization.

John B.

---

From: Dirkjan Ochtman <[email-masked]>
Date: Tue, 12 Nov 2013 22:15:08 +0100

> Mainly because I'm interested, can you give the working group some background on why you decided to use DSA?

I wasn't participating at the time, but someone who was mentioned that
performance was a concern. We're especially limited here because we
execute some things in JavaScript on clients with less than stellar
performance characteristics.

Cheers,

Dirkjan

---

From: Dirkjan Ochtman <[email-masked]>
Date: Tue, 12 Nov 2013 22:17:08 +0100

> Are you wanting Specifically Bernstein's 25519 curve or some more general curve agility?

I have no particular attachment to any curves, but from what I'm
seeing in some chatter among prominent cryptographer's, the NIST
curves are kind of suspect (I think the SafeCurves site makes this
argument quite well), and Bernstein's curves (the 25519 one in
particular) seem to be popular as alternatives.

Cheers,

Dirkjan

---

From: Dirkjan Ochtman <[email-masked]>
Date: Thu, 21 Nov 2013 12:14:42 +0100

> verification, and very fast key generation and signing are attractive.

Is there a particular reason you didn't reuse the "crv"/"x"/"y" keys
used by other curves?

> Anyone will be able to register algorithm identifiers in the algorithms registry, with the only requirement being that a document is written that specifies the algorithm behavior.  So you could def…

Does "will be" signify that you think no further algorithms should be
added before finalization as an RFC? Is there a current raw estimated
time to completion?

> We restricted the curves initially in favour of getting interoperability as opposed to using arbitrary curves.

That's understandable on one hand; on the other hand, if some other
curves are rapidly gaining popularity, it seems sensible to me to
include them now rather than hold off on standardization with the risk
that early adopters start implementation in subtly-incompatible ways
(as it seems has already happened given Daniel Holth's experience). We
are strongly interested in Ed25519; it's looking like the ChaCha20
stream ciper and the Poly1305 MAC are also rapidly gaining popularity
(including implementation in OpenSSL/OpenSSH and NSS/Chrome).

Cheers,

Dirkjan

---

From: Daniel Holth <[email-masked]>
Date: Thu, 21 Nov 2013 07:02:06 -0500

> Is there a particular reason you didn't reuse the "crv"/"x"/"y" keys

Simply because Ed25519 does not expose those parameters.

> > Anyone will be able to register algorithm identifiers in the algorithms
registry, with the only requirement being that a document is written that
specifies the algorithm behavior.  So you could define DS128, etc. and
register them if you choose.
> > We restricted the curves initially in favour of getting
interoperability as opposed to using arbitrary curves.

---

From: Mike Jones <[email-masked]>
Date: Thu, 21 Nov 2013 15:54:22 +0000

"will be" signifies that registrations will be possible once the registry has been established, which will happen when JWA is an RFC.

Does the verifying key not have the structure of a pair of x, y values?  It would surprise me if it didn't.  And I'd think you'd want to use something like "crv":"ed25519" as the curve name in the JWK representation.

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Daniel Holth
Sent: Thursday, November 21, 2013 4:02 AM
To: Dirkjan Ochtman
Cc: jose
Subject: Re: [jose] JWS algorithms: DSA, non-NIST curves

On Nov 21, 2013 6:15 AM, "Dirkjan Ochtman" <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Tue, Nov 12, 2013 at 2:27 PM, Daniel Holth <[email-masked]<mailto:[email-masked]>> wrote:

> On Tue, Nov 12, 2013 at 8:01 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
> On Tue, Nov 12, 2013 at 8:54 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Richard Barnes <[email-masked]>
Date: Thu, 21 Nov 2013 11:01:33 -0500

Indeed, according to the EdDSA papers, a public (verifying) key is an EC
point, and the private (signing) key is an integer.
<http://ed25519.cr.yp.to/ed25519-20110926.pdf>

So the existing "x", "y", and "d" parameters would be sufficient.  You
would just need new values for "alg" and "crv".

--Richard

On Thu, Nov 21, 2013 at 10:54 AM, Mike Jones <[email-masked]>wrote:

>  “will be” signifies that registrations will be possible once the
> registry has been established, which will happen when JWA is an RFC.
>
>
>
> Does the verifying key not have the structure of a pair of x, y values?
> It would surprise me if it didn’t.  And I’d think you’d want to use
> something like “crv”:”ed25519” as the curve name in the JWK representation.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* jose [mailto:[email-masked]] *On Behalf Of *Daniel Holth
> *Sent:* Thursday, November 21, 2013 4:02 AM
> *To:* Dirkjan Ochtman
> *Cc:* jose
> *Subject:* Re: [jose] JWS algorithms: DSA, non-NIST curves
>
>
>
>
> > > Anyone will be able to register algorithm identifiers in the
> algorithms registry, with the only requirement being that a document is
> written that specifies the algorithm behavior.  So you could define DS128,
> etc. and register them if you choose.
> >

---

From: Daniel Holth <[email-masked]>
Date: Thu, 21 Nov 2013 12:50:04 -0500

On Thu, Nov 21, 2013 at 11:01 AM, Richard Barnes <[email-masked]> wrote:
> So the existing "x", "y", and "d" parameters would be sufficient.  You would
> just need new values for "alg" and "crv".

The implementation does not accept an x, y, or curve parameter. The
public/verifying and private/signing keys are each compressed
representations of x and y and would take up twice the space if
represented as (x, y). IMO this lack of parameters is a major feature
of the Ed25519 algorithm. It implements the recommended parameters
from the EdDSA paper in an optimized way.

My implementation does store a redundant copy of the public key as
half of the signing key. I have not worried about that yet since it is
not transmitted; I don't personally need my private/signing key to be
a JWK.

In the signing key the 256 truly private bits are just the random
number seed used to generate the other keys. IIUC [in the simple API]
the secret curve point is generated from a hash of these bits during
each signature.

The Python implementation at http://ed25519.cr.yp.to/software.html
might be helpful.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 21 Nov 2013 13:16:52 -0500

On Thu, Nov 21, 2013 at 12:50 PM, Daniel Holth <[email-masked]> wrote:

> would

Honestly, I don't really care format what the software takes.  It's pretty
trivial to convert between the compressed format and (x,y).

On the other hand, I could see defining something different for the private
key, since it's not directly a point multipler.

--Richard

---

From: Daniel Holth <[email-masked]>
Date: Thu, 21 Nov 2013 14:11:45 -0500

> trivial to convert between the compressed format and (x,y).

I'm not sure which way you're arguing here.

I also like to just use the 32-byte public key instead of or as the
kid (just transmitting the public key with each signature).

> key, since it's not directly a point multiplier.

Would be cool to see Ed25519 in this spec. It has been a useful
specification so far. That is all.

---

From: Mike Jones <[email-masked]>
Date: Mon, 25 Nov 2013 20:01:13 +0000

The decisions about what algorithms to include and what implementation requirements to place on them has largely been data driven.  The working group produced a survey of what algorithms are implemented on what development platforms (attached) and used it to drive these decisions.  For the most part, those algorithms that are commonly implemented by the libraries are required, and those that are not, are not.  The goal was the broadest practical interoperability possible.

				-- Mike

-----Original Message-----
From: Daniel Holth [mailto:[email-masked]] 
Sent: Thursday, November 21, 2013 11:12 AM
To: Richard Barnes
Cc: Mike Jones; Dirkjan Ochtman; jose
Subject: Re: [jose] JWS algorithms: DSA, non-NIST curves

> Honestly, I don't really care format what the software takes.  It's 
> pretty trivial to convert between the compressed format and (x,y).

I also like to just use the 32-byte public key instead of or as the kid (just transmitting the public key with each signature).

> On the other hand, I could see defining something different for the 
> private key, since it's not directly a point multiplier.

Would be cool to see Ed25519 in this spec. It has been a useful specification so far. That is all.