Ed25519 and ChaCha20+Poly1305 in crypto/ssh

[Jonathan Rudenberg]

I’d like to see Ed25519 key[0] support and ChaCha20+Poly1305[1] added to the crypto/ssh package. I’m happy to attempt an implementation and submit patches, but it looks like implementations of Ed25519 and ChaCha20 are not currently in the crypto subrepo.

AGL has an implementation of Ed25519[2], and Coda Hale has an implementation of ChaCha20[3] available on GitHub.

This raises the following questions:

Is it possible to pull these implementations into the crypto subrepo?
Are the authors willing to do so? (I’m happy to help in any way that I can)
Are there any reasons why these implementations should not be used?

Thanks,

Jonathan

[0] https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-December/031871.html
[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?rev=1.2&content-type=text/plain
[2] https://github.com/agl/ed25519
[3] https://github.com/codahale/chacha20

[Anthony Martin]

> I’d like to see Ed25519 key[0] support and ChaCha20+Poly1305[1] added
> to the crypto/ssh package. I’m happy to attempt an implementation and
> submit patches, but it looks like implementations of Ed25519 and ChaCha20
> are not currently in the crypto subrepo.

I'm also interested in ChaCha20 and Poly1305 for crypto/tls.

Cheers,
Anthony

[Adam Langley]

On Wed, Dec 10, 2014 at 1:21 PM, Jonathan Rudenberg
<jona...@titanous.com> wrote:
> Is it possible to pull these implementations into the crypto subrepo?
> Are the authors willing to do so? (I’m happy to help in any way that I can)
> Are there any reasons why these implementations should not be used?

It's certainly possible to move ed25519 in (although I would probably
leave the "extra25519" package behind).

ChaCha20 is simple enough that it could be implemented pretty easily,
even if codahale doesn't want to submit.


Cheers

AGL

[Coda Hale]

I’d be happy to contribute my ChaCha20 implementation. I have a CL ready to go, but then tragedy struck:

> $ git review mail
> remote: Permission to golang/crypto.git denied to codahale.
> fatal: unable to access 'https://github.com/golang/crypto/': The requested URL returned error: 403
> git push -q origin HEAD:refs/for/master
> git-review: exit status 128

I’ve never submitted a patch to the Go project or subprojects before, so I have no idea what I’m screwing up. Some off-list help would be much appreciated.

---
Coda Hale
http://codahale.com

[Coda Hale]

Thanks to some astute help from Jonathan, we’re good to go:

https://go-review.googlesource.com/1363

---
Coda Hale
http://codahale.com

[Jonathan Rudenberg]

> On Dec 11, 2014, at 11:11 AM, Coda Hale <coda...@gmail.com> wrote:
>
> Thanks to some astute help from Jonathan, we’re good to go:

Awesome! I submitted an issue about the error you ran into: https://github.com/golang/go/issues/9266

[Adam Langley]

On Thu, Dec 11, 2014 at 7:59 AM, Coda Hale <coda...@gmail.com> wrote:
> I’d be happy to contribute my ChaCha20 implementation. I have a CL ready to go, but then tragedy struck:
>
>> $ git review mail
>> remote: Permission to golang/crypto.git denied to codahale.
>> fatal: unable to access 'https://github.com/golang/crypto/': The requested URL returned error: 403
>> git push -q origin HEAD:refs/for/master
>> git-review: exit status 128
>
> I’ve never submitted a patch to the Go project or subprojects before, so I have no idea what I’m screwing up. Some off-list help would be much appreciated.

(The new, git based system is not yet ready to go. There'll be an
email about 1.5 opening once it is.)


Cheers

AGL

[Bryan Ford]

AGL's implementation of Ed25519 is awesome, and I'd love to see it in go.crypto.  One caveat, though, is that while the Ed25519 curve itself and most of the Ed25519 code is in principle usable in a wide variety of public-key crypto algorithms and protocols, the current ed25519 package is completely specific to just one public-key signature scheme.  If ed25519 is included in go.crypto as-is, it will already embody some functional overlap with the existing curve25519 package (which implements a different representation of the same basic curve).  Continuing this approach will invite further functional duplication down the road if/when other curve25519-based public-key algorithms get incorporated into go.crypto, as seems likely.  The different and separately-optimized curve representations may justify keeping curve25519 and ed25519 separate, but it would be nice to avoid a new copy of the curve25519 or ed25519 code for every new public-key algorithm that uses either of these curve representations.

In our group's work-in-progress advanced crypto library, one thing we've done is generalize AGL's ed25519 implementation to be more general and usable in arbitrary public-key crypto algorithms; for example we're using it for general zero-knowledge proofs, verifiable shuffles, etc.  The generalized ed25519 code is here:

http://godoc.org/github.com/DeDiS/crypto/edwards/ed25519

...and the abstract elliptic-curve-arithmetic interfaces it implements are defined at:

http://godoc.org/github.com/DeDiS/crypto/abstract

In this framework, for example, either Ed25519 or the NIST curves already supported in the Go standard library can be used interchangeably in public-key algorithms that no longer need to know or care exactly which curve they're using.

Incorporating a general framework like this of course would be a bigger deal than just incorporating ed25519 for digital signing support, and I'm not proposing that it needs to or should be done right now; I would just prefer to see something like this happen at some point rather than to see a gradually increasing proliferation of algorithm-specific variants of the same underlying elliptic curves appearing in the go.crypto library.

Cheers

Bryan

[Adam Langley]

On Sat, Dec 13, 2014 at 1:06 PM, Bryan Ford <bryno...@gmail.com> wrote:
> AGL's implementation of Ed25519 is awesome, and I'd love to see it in
> go.crypto. One caveat, though, is that while the Ed25519 curve itself and
> most of the Ed25519 code is in principle usable in a wide variety of
> public-key crypto algorithms and protocols, the current ed25519 package is
> completely specific to just one public-key signature scheme. If ed25519 is
> included in go.crypto as-is, it will already embody some functional overlap
> with the existing curve25519 package (which implements a different
> representation of the same basic curve). Continuing this approach will
> invite further functional duplication down the road if/when other
> curve25519-based public-key algorithms get incorporated into go.crypto, as
> seems likely. The different and separately-optimized curve representations
> may justify keeping curve25519 and ed25519 separate, but it would be nice to
> avoid a new copy of the curve25519 or ed25519 code for every new public-key
> algorithm that uses either of these curve representations.

Agreed. The guts are already exposed in a subpackage[1] but that's not
sufficiently commented and organised for go.crypto. However, a simpler
interface also risks being ignored because of efficiency reasons: if
it's not possible to hold intermediate values in specific
representations then the conversions will kill you.

A good interface for the curve25519 guts would allow Elligator, SPAKE2
etc to be easily implemented on top of it too. That would certainly be
nice, although I wouldn't block the inclusion of ed25519 based on it.


Cheers

AGL

[1] http://godoc.org/github.com/agl/ed25519/edwards25519