[Cryptography] programming languages and the people who (don't) love them, was "NSA-linked Cisco exploit poses bigger threat than previously thought"

Brian Smith brian at briansmith.org
Sat Aug 27 05:00:11 EDT 2016


John Levine <johnl at iecc.com> wrote:
>>> ObCrypto: very little of the crypto code I use has to run in the kinds
>>> of environments where C's advantages are important, so it's a reasonable
>>> question why application libraries like openssl are still in C.
>>
>>It is still important that crypto code be callable as efficient
>>libraries. One wouldn't want to, say, instantiate an entire Python
>>environment every time the caller starts a new hash or encryption. And
>>it seems a good idea to program pretty close to the metal to head off
>>timing attacks, not let keys drift off into garbage collection land, etc.
>
> Of course, but there are languages like Rust that purport to provide
> code efficiency comparable to C's with better type safety, and can use
> calling sequences compatible with C.
>
> Now I'm wondering how much of the problem is library management and
> build tools that make it too hard to combine code written in different
> languages, or perhaps programmers who still find programming in
> multiple languages too hard.

A significant subset of OpenSSL being renovated in Rust:
https://github.com/briansmith/ring

X.509 certificate validation in the pure Rust (no `unsafe`), on top of *ring*:
https://github.com/briansmith/webpki

TLS 1.2 in pure Rust (no `unsafe`), on top of webpki and *ring*:
https://github.com/ctz/rustls

The beginnings of a C ABI for *ring*:
https://github.com/briansmith/ring-ffi

An example of Python bindings to the small subset *ring* exposed by the C ABI:
https://github.com/reaperhulk/cryptography-ring

Patches welcome.

Cheers,
Brian
-- 
https://briansmith.org/


More information about the cryptography mailing list