FAQ
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

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Anthony Martin at Dec 10, 2014 at 10:45 pm

    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

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Adam Langley at Dec 11, 2014 at 12:12 am

    On Wed, Dec 10, 2014 at 1:21 PM, Jonathan Rudenberg 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

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Coda Hale at Dec 11, 2014 at 3:59 pm

    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
    On Dec 10, 2014, at 13:21, Jonathan Rudenberg wrote:

    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
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Coda Hale at Dec 11, 2014 at 4:11 pm
    Thanks to some astute help from Jonathan, we’re good to go:

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

    ---
    Coda Hale
    http://codahale.com
    On Dec 11, 2014, at 07:59, Coda Hale 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.

    ---
    Coda Hale
    http://codahale.com
    On Dec 10, 2014, at 13:21, Jonathan Rudenberg wrote:

    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
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jonathan Rudenberg at Dec 11, 2014 at 4:15 pm

    On Dec 11, 2014, at 11:11 AM, Coda Hale 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

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Adam Langley at Dec 11, 2014 at 4:45 pm

    On Thu, Dec 11, 2014 at 7:59 AM, Coda Hale 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

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bryan Ford at Dec 13, 2014 at 9:06 pm
    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



    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Adam Langley at Dec 15, 2014 at 7:28 pm

    On Sat, Dec 13, 2014 at 1:06 PM, Bryan Ford 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

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedDec 10, '14 at 9:21p
activeDec 15, '14 at 7:28p
posts9
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase