Figure out in-tree crypto story

[brson]

We've previously made the decision not to distribute any crypto with Rust at all, but this is probably not tenable since crypto is used everywhere. My current opinion is that we should not distribute any crypto written in Rust, but that distributing bindings to well-regarded crypto is fine.

Figure out a strategy here, build consensus, then start implementing a robust crypto library out of tree, with the goal of merging into the main distribution someday. There are some existing efforts along these lines that should be evaluated for this purpose.

[emberian]

There's some pure-Rust work on https://github.com/DaGenix/rust-crypto. http://nacl.cr.yp.to/ is probably among the most trustworthy libraries at this point, but hasn't been (to my knowledge) widely deployed.

[emberian]

(http://cr.yp.to/highspeed/coolnacl-20120725.pdf)

[emberian]

See also https://github.com/jedisct1/libsodium and http://cryptojedi.org/papers/tweetnacl-20131229.pdf

[emberian]

Oh, and I almost forgot about https://github.com/dnaq/sodiumoxide, which is an initial attempt at binding libsodium

[DaGenix]

Is the goal of the crypto library to provide rust interfaces to a wide set of commonly used algorithms? If so, I don't think NaCL / libsodium are a great fit since I don't believe they include algorithms such as MD5 or TLS.

[wsddn]

For just making things secure NaCL seems to be the go to library, but it only supports certain cryptographic primitives which make it not at all useful for a library that wants to provide general cryptographic code. It is not designed to be a general purpose one stop shop cryptographic library. For example it will be impossible to create a standards complying TLS implementation with NaCL because it does not provide AES CBC.

Some cryptographic functions that NaCL does not support:

• Some AES modes (CBC, CFB, GCM)
• ChaCha20 (Salsa20 and XSalsa20 are provided, ChaCha20 is just a slight tweak on Salsa20 for greater speed and possibly security)
• RSA
• Elliptical Curves (NIST / Brainpool, the NIST curves are controversial though)
• ECDSA
• DSA
• Diffie-Hellman key exchange (NaCL provides curve25519 which is a curve used in Elliptical Curve Diffie Hellman)
• MD5 hashing (although is providing a universally shunned hash system a good idea?)
• SHA1

For what its worth Go implements most of their cryptographic code in Go (however Adam Langley has admitted that they have not mitigated timing attacks in their crypto/rsa package).

[Ayrx]

FWIW, I am contributor to the cryptography library for Python. You can consider taking the approach we did here and design a "pluggable" API that bindings existing C libraries. For a general purpose crypto library, NaCL is almost definitely not a good fit because common algorithms aren't present in it. While there has been much bad press about OpenSSL lately, it is really the most viable library to wrap since it is available on all common platforms and almost certainly already installed on Linux distros. The current scrutiny on it should do well to turn up security bugs as well. Our API also allows other C libraries to be used (we bind commoncrypto on OS X as well, and I have PolarSSL bindings in the works.)

If designed well, I can see the potential Rust crypto library at first being dependent on C bindings but eventually gets seamlessly replaced by Rust code without much backwards incompatibility.

[sdevlin]

I highly recommend you package something like NaCl as a high-level crypto interface - call it "crypto/box" or similar. This is the package you want the vast majority of application developers to use.

Other specific protocols should similarly be packaged in high-level interfaces when it makes sense to provide them, e.g. "crypto/tls".

While a lower-level set of primitives is necessary for protocol implementers, documentation and naming conventions should steer people away from them. Call this package "crypto/low-level" or "crypto/arcane" or something like that.

[taoeffect]

This Rust crypto library should be mentioned (surprised it hasn't been): ClearCrypt

[emberian]

ClearCrypt is not a general-purpose crypto library but an implementation of
an encryption protocol

On Thu, Jun 5, 2014 at 10:04 AM, Greg Slepak notifications@github.com
wrote:

This Rust crypto library should be mentioned (surprised it hasn't been):
ClearCrypt https://github.com/clearcrypt/clearcrypt

—
Reply to this email directly or view it on GitHub
#14655 (comment).

http://octayn.net/

[taoeffect]

@cmr: ClearCrypt contains many parts of a general-purpose crypto library, similar to how OpenSSL does (though it's an implementation of the SSL/TLS protocol).

[emberian]

It doesn't now, and since it won't have the mess of supported ciphers etc
that TLS does, I doubt it will (and it shouldn't!).

On Thu, Jun 5, 2014 at 10:14 AM, Greg Slepak notifications@github.com
wrote:

@cmr https://github.com/cmr: ClearCrypt contains many parts of a
general-purpose crypto library, similar to how OpenSSL does (though it's an
implementation of the SSL/TLS protocol).

—
Reply to this email directly or view it on GitHub
#14655 (comment).

http://octayn.net/

[taoeffect]

Right, it's a WIP, I just wanted to mention it. I hope I didn't offend you by doing so. ;)

[erickt]

We do also have the https://github.com/sfackler/rust-openssl bindings, maintained by @sfackler and myself.