[bluejekyll]

I love the idea of a zero allocation crypto library, but isn't the fact that this is also in C going eventually lead down a similar path as that of OpenSSL?

I'm personally really excited for this: https://github.com/briansmith/ring

It's a Rust oxidization of the BoringSSL library, meaning that parts of BoringSSL are being rewritten in Rust, with the eventual goal of being pure Rust.

[lambda]

> with the eventual goal of being pure Rust

No, being pure Rust is not the goal. It aims to use Rust as much as possible for the parts that Rust is good at. But core crypto algorithms generally need to be written in assembler, to avoid various timing attacks that could be introduced by optimization. And for things that would require large amounts of `unsafe` in Rust, there's less reason to port that to Rust, and leaving it in C can be more clear.

See the style guidelines from the project:

https://github.com/briansmith/ring/blob/master/STYLE.md#unsa...

The thing that are most appropriate for Rust are parsing, protocol implementation, higher level code that uses core crypto primitives, and providing a safe API to client code. But the core crypto primitives themselves will remain written in C and/or assembler, as appropriate.

[frutiger]

> to avoid various timing attacks that could be introduced by optimization

Assembler only goes so far. Until you figure out how the processor's front end will decode the machine code and run the underlying RISC program, or how the hypervisor will schedule your program on some shared machines (e.g. in EC2) you're susceptible to a different class of side-channel attacks.

[tptacek]

This is true but not relevant to the discussion: whatever side channel problems you'd have in pure assembly, you're practically certain to have more of them if you implement crypto in a high-level language with an aggressive optimizer.

[frutiger]

Note I never disagreed with GGP's premise - I'm only pointing out that you can go further than assembler.

[bradleyjg]

Is there any way to write programs that bypass the processor's front end for most the processors in use? If not, it what sense is it true that "you can go further than assembler"?

[frutiger]

You don't have much choice with commodity hardware - but you could perform crypto on hardware/chips where the behavior is completely specified.

Note that this is not very practical, and impractical crypto is almost as good as no crypto.

[Sir_Cmpwn]

The problem with OpenSSL is less about the language it's written in and more about the age of the project, discipline of the developers, quality of the codebase, and its prevalance - which leads to its vulnerabilities having a high impact. OpenSSL's code is a heap of trash and that's why it's vulnerable, not neccessarily because it's written in C.

[bluejekyll]

Sure. Though, C does nothing to help prevent you from creating that same garbage again.

So while there are excellent examples of C projects out there, there are many more that show why it's important to provide developers (even the good ones) with guard rails.