r00t2/go_chacha20poly1305_openssh
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
A variant of ChaCha20-Poly1305 that OpenSSH uses ("chacha20-poly1305@openssh.com").
7 Commits 1 Branch 1 Tag 443 KiB
Go 99.7%
Shell 0.3%
5fb3085848
Go to file
brent s 5fb3085848
adding git hook test, simplified structure using vendoring
2023-01-09 05:50:26 -05:00
.githooks/pre-commit adding git hook test, simplified structure using vendoring 2023-01-09 05:50:26 -05:00
vendor adding git hook test, simplified structure using vendoring 2023-01-09 05:50:26 -05:00
.gitignore adding upstream libs 2022-06-05 06:52:27 -04:00
consts_test.go adding git hook test, simplified structure using vendoring 2023-01-09 05:50:26 -05:00
consts.go adding git hook test, simplified structure using vendoring 2023-01-09 05:50:26 -05:00
go.mod adding git hook test, simplified structure using vendoring 2023-01-09 05:50:26 -05:00
go.sum adding git hook test, simplified structure using vendoring 2023-01-09 05:50:26 -05:00
notes simplify this down 2023-01-08 17:31:09 -05:00
README.md adding git hook test, simplified structure using vendoring 2023-01-09 05:50:26 -05:00

README.md

cc20p1305ssh

A Golang library variant of ChaCha20-Poly1305 that OpenSSH uses ("chacha20-poly1305@openssh.com").

Note that this module only supports the OpenSSH variant.

Why is this necessary?

Because Golang.org/x/crypto removes functionality (even for very common tech) and thinks OpenSSH is a "weird" use case.

I really, really hope this library is no longer necessary by the time I'm done writing it, but based on my past experiences with core Golang devs, my expectations are extremely low.

They have no decent support for OpenSSH keys or lower-level operations. And guess what -- sometimes you need lower-level functionality. Who knew?

So now because I'm just a single individual, bug fixes will probably lag behind upstream. All because Golang.org/x/crypto decided the OpenSSH variant was "too weird".

But, of course, not "weird" enough to not support the wire protocol for SSH. Just the key encryption. Because of course. And not publicly exposed either. Because of course.

Why is the name so ugly?

I couldn't think of a better one and I wanted something notably distinct from stdlib-x.

Why don't you expose the rest of ChaCha20/Poly1305/ChaCha20-Poly1305?

  • To keep code light (and thus easier to debug, audit, etc.)
  • Because otherwise the module name is inaccurate
  • Because OpenSSH has their own specific variant
    • Which means we can handle SSH-specific functionality if needed
  • Because Golang/x/crypto has made it painfully clear that if you want something that deviates from what they think is "best practice", you need to do it yourself

Based on golang.org/x/crypto/chacha20poly1305 (source specifically forked from chacha20poly1305, chacha20, and poly1305), sliced, diced, and ripped to pieces. Based from commit 793ad666bf5ec61392092b27061be9618e4e219b via repo https://github.com/golang/crypto.git (mirror of git://cs.opensource.google/go/x/crypto), fetched on Jun 5, 2022 at 0656EST5EDT.

Because the code is minimally modified, the majority of the code's original license can be found via LICENSE.forked (of which the source can be found above).

Namely, some of these specific modifications are:

  • "Exporting" certain previously private methods
  • "Exporting" certain previously private struct fields
  • Changing certain constants and logic conditions