[rdeboo]

I used to think that; but I'm following Dan Boneh's crypto course on Coursera at the moment, and he specifically notes that you should not even try to implement known algorithms yourself (for production; you could do it ofcourse for the learning experience).

The reason is that there are subtle attacks on the implementation, such as timing attacks, which can leak information.

[pornin]

One of the point of the exercise is to provide constant-time implementations that provably do not leak such information. The hash functions, two AES, one DES/3DES, RSA and elliptic curve implementations in BearSSL have been written to be constant-time. I still have to write some document that explains how such things are done.

[near]

This thinking is why Heartbleed was such a disaster. Everyone left it to someone else, and the end result was OpenSSL being the only serious choice. Yet even the 'experts' got it wrong -- way wrong.

I'm not advocating everyone and their mother implement their own crypto. But some software diversity is a good thing. These algorithms aren't quite as scary or fickle as the documentation and existing implementations make them seem. Especially if you stick to good software like DJB's stuff.

For instance, using montgomery/edwards curves instead of weierstrass curves eliminates a lot of the difficulty in writing a constant-time implementation of ECC. And the 25519 implementation comes with a fast, constant-time implementation of a prime field type.

Yet even DJB's stuff can be simplified. You can knock off a good 80% of the scary code at a cost of a mere 10% of performance. To Google or Facebook, that may be unacceptable. But to me, that's entirely worth it. Now you have a tiny library that is easy to understand, and easy to audit.

[oconnor663]

> Yet even DJB's stuff can be simplified. You can knock off a good 80% of the scary code at a cost of a mere 10% of performance.

Wouldn't you say DJB (et al) did that themselves? https://tweetnacl.cr.yp.to/

[byuu]

I haven't benchmarked TweetNaCl's performance yet, but I think that goes way too far into making the code completely unreadable. The 80%/10% number I gave is against the ref10 implementation.

Compare theirs: https://tweetnacl.cr.yp.to/20140427/tweetnacl.c

To mine:

https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur...

https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur...

https://gitlab.com/higan/higan/blob/master/nall/cipher/chach...

https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305...

https://gitlab.com/higan/higan/blob/master/nall/hash/sha256....

Please note that like BearSSL, my implementations are alpha-quality. Further, I'm not suggesting anyone use these in production. If I do so myself and it blows up in my face, it'll only have harmed me, and I'll only have myself to blame.

(Also, I'm really bad when it comes to source code comments, sorry. The why really needs you to read the research papers; the how is mostly self-evident. The remaining one-letter variable names were used to match the papers, and because I couldn't think of more descriptive terms.)

[duneroadrunner]

If you're using modern C++ you might consider using SaferCPlusPlus[1] for improved memory safety. Safe, fast compatible direct substitutes for C++'s unsafe elements (pointers, arrays, vectors, even references are technically unsafe). Small, easy to use, no dependency risk, and can be optionally "disabled" with a compile-time directive. It's the best answer to the Rust crowd who (justifiably) point out the inevitability of memory bugs in large enough C++ code bases.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[wolf550e]

To me, C++ with operator overloading looks scary. I think a reviewer would choose to review the generated binary instead of the source code.

[revelation]

Well if operator overloading looks scary you haven't seen the assembly generated for C++ programs ;)

It's just full with con-/de-structor noise and don't even get me started with virtual function calls.

[mSparks]

cant be any worse than openssl.

they have all code running in constant time from the alpha version.

Next comes making sure there are no buffer overflows. the code is stable and compatible.

If everyone leaves it to someone else who does it exactly?

Obviously not ready for use in production until its been audited.

Remind me again where i can download an audited ssl implimentation?

[BillinghamJ]

> cant be any worse than openssl.

Not sure I'd agree with that. OpenSSL is very far from perfect and obviously contains many many security bugs, but it also has a very long history of fixes, knowledge, etc. and has a large number of eyes on it. It's more of a known quantity than something new.

[wbl]

OpenSSL does not have half the fixes people think it does. Generally what gets fixed is the ciphersuites some people happen to use, and the rest remain broken. For example, the constant time ECDSA signing only works with some curves, not all. It still supports horrific hacks for random number generation, instead of using OS provided interfaces. NSS is not much better on this front, but does a far better job of parsing TLS records in a sane way.

[mSparks]

well. actually looks better from the start:

There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.)

On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.