In principle, there should exist Rust crypto libraries. I would be happy to implement them, but there are a couple of competing forces at work, and I'd like opinions. First, the forces:
1) The more portable, the better. 2) All other things being equal, Rust code is better than native code. 3) Writing one's own crypto is historically a very poor idea. The options: 1) Write our own crypto from scratch, in Rust. 2) Write bindings for OpenSSL's libcrypto. 3) Write bindings for something else external. 4) Pull something else external into rustrt, write bindings for that. My evaluations: I think option 1 is a nonstarter, at least for me, since a) I'm not really qualified to do it, b) it would have ~0 eyes on it, most likely and c) the world really doesn't need another crypto implementation from scratch with different bugs and a different subset of features. Option 2 is tempting, but libcrypto is _large_ (~1.7M on my system). The advantage of this is that we don't need to pull libcrypto into the basis, since openssl is installed on basically every system. This also gives us support for a truly huge selection of cryptographic primitives. Option 3 is also tempting. There are a lot of other libraries, but they all seem to fall along a sliding scale between "elephantine" and "un-audited", with OpenSSL at one extreme and things like PolarSSL at the other. Option 4 is probably not a very good idea. Doing this leaves us responsible for picking up upstream security fixes to the library we'd have pulled in, and if we picked a large, well-audited one (e.g. OpenSSL) would increase our source tree size and build times commesurately. On the other hand, if we do this, every Rust program can depend on having crypto primitives present at all times. I'm leaning toward option 2, I think. Does anyone have other thoughts? -- elly
signature.asc
Description: Digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
