Add "DJB" algorithms

[public]

We currently have pretty good support for NIST stuff but it would be nice to have some modern non-NIST algorithms too.

• Poly1305-AES
• Ed25519
• ChaCha20
• Curve25519

This would probably require a new (optional?) backend dependency.

[techtonik]

Looks like Curve25519 is not exactly Ed25519 - http://stackoverflow.com/a/19162037/239247

[ronf]

That's true - they're not the same. For Curve25519, there's a good Python implementation available from Adam Langley at:

https://github.com/agl/curve25519-donna/tree/master

Curve25519 support would be useful for SSH, as there is a key exchange method supported by OpenSSH based on it.

[techtonik]

Here is Ed25519 in pure Python https://github.com/vbuterin/ed25519

[ronf]

Ed25519 is also available via libnacl, which is a thin Python wrapper around libsodium. More information is available at:

http://libnacl.readthedocs.org/en/latest/topics/raw_sign.html

I'm using it to support Ed25519 public keys in AsyncSSH. My use of that can be found here:

https://github.com/ronf/asyncssh/blob/master/asyncssh/ed25519.py

Via libnacl/libsodium, I have also been able to support Curve25519 based key exchange, the Chacha20 cipher, and the Poly1305 MAC algorithm, though I had to extend the libnacl wrapper and directly access libsodium to get at some of those.

[reaperhulk]

@ronf there's also https://github.com/pyca/pynacl, although I'm not super involved in that project so I can't tell you what the advantages or disadvantages of it vs libnacl are.

[ronf]

@reaperhulk Yes, and there's another thin wrapper around libsodium called pysodium at https://github.com/stef/pysodium. The main thing that attracted me to libnacl is that since it was already using ctypes to expose the libsodium APIs, it was very easy for me to add my own hooks into other APIs there that it didn't expose yet that weren't part of the standard "nacl" interface. I needed those to implement the variant of chacha20-poly1305 that is used in SSH. I didn't have to touch the crypto at all, but I did need to construct the messages slightly differently.

It looks like libsodium is also a ctypes wrapper, and I probably could have used that in a similar fashion to what I did with libnacl, but I don't remember seeing that when I first looked.

[shea256]

So a few of the common contributors to pyca projects have made this pure python implementation of ed25519: https://github.com/pyca/ed25519, and it looks like pynacl uses the c implementation.

I'm a bit confused, though. Does Cryptography currently have ed25519 integrated?

[reaperhulk]

No, the cryptography project itself does not support ed25519 at this time

[shea256]

OK thank you. Was this a conscious decision? Do you plan on adding support for it at some point?

[reaperhulk]

It's a natural result of the way our backends currently work. We don't have a good way of handling optional backends so we've limited our surface area to what we can accomplish using OpenSSL. Since OpenSSL doesn't have ed25519 (although it might in the future) we haven't supported thus far.

In the longer term we'd like to have a way to install optional backends that can replace or supplement the openssl and commoncrypto backends, but we're not there yet.

[shea256]

OK thank you. I'll check out pynacl then.

[reaperhulk]

We'll be adding quite a few of these in the near future with #2968 and ed25519 will likely come in a future OpenSSL. Closing in favor of the newer ticket.