A security review of the D library Crypto

[sarn]

On Wednesday, 1 July 2020 at 11:54:54 UTC, Cym13 wrote:
> On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote:
>> It also illustrates what's the prolem with cryptography: it's 
>> like coding without ability to test. Who could even dream to 
>> get that right the first or even the second time? I think 
>> there a shortcoming in the "don't roll your own crypto" - 
>> advice: One could think it only applies to the algorithms, not 
>> the implementation. That's what I did when I first heard it.
>
> There's one more element missing here: the protocol. 
> Cryptography isn't about encrypting stuff, it's about 
> protecting secrets from start to finish and that includes the 
> protocol used. To take an example, many people can think "Hey, 
> I need encryption between my two servers, I'll use AES" and 
> stop there. But use AES how? What mode (CBC,GCM,...)? Let's say 
> CBC is used, what about message authentication? Can I just 
> modify your stream? How is the key exchanged? How is the key 
> generated? Etc.
>
> People tend to focus on encryption, be it algorithm or 
> implementation, but once you've got bricks it's still a pain to 
> put them together in a solid way. Things like TLS or SSH 
> actually combine at least 3 completely different sets of bricks 
> to establish the communication, authenticate it, secure it once 
> established etc.
>
> So, in a way, "don't roll your own crypto" means "use TLS as 
> much as possible" :)

Some people don't want to hear all that because implementing 
crypto is exciting.  So I like to recommend this problem set 
instead:
https://cryptopals.com/
It scratches the "I wanna write crypto" itch, and it makes the 
"custom crypto is easier to break than you might think" point 
really well.

(By the way, your article had really good depth.  I'm subscribing 
to your RSS :)