A security review of the D library Crypto

[Cym13]

On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote:
> On Wednesday, 1 July 2020 at 07:19:11 UTC, Cym13 wrote:
>> Here's what you should know if you are a user:
>>
>> RSA, as implemented in the library, is still very much broken. 
>> I do not recommend using it. The confidentiality and integrity 
>> of all messages exchanged using this library must be 
>> questionned: if you exchanged sensitive information such as 
>> passwords using it I recommend to change them since their 
>> security is not guaranteed.
>>
>> [snip]
>
> Thanks for the article. IMO it was as clear for 
> non-professionals as crypto can be: Even I (non-crypographer) 
> understood what's the problem with padding with only one byte.

Thank you for that feedback.

> 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" :)

> If one needs to use cryptography, would redundancy help? I 
> mean, encode and decode the message with say three different 
> algorithms from different libraries, so that the attacker would 
> need to find a weakness in all of them?

That's a good question. The general answer is: no.

The more detail answer is: in some cases it can help (I know of 
one client for example that doesn't trust national standards and 
has layered US technology with Russian technology to make sure 
that at least one layer stands).

However in the general case we can prove that the security of the 
combination is less than or equal to the security of the better 
of the elements of that combination. In some cases badly choosen 
algorithm actually counteract each other leading to easier 
attacks.

My general advice is to stay true to well audited implementations 
of good standards. I like opiniated libraries in that context so 
I'd say "whatever libsodium implements".