Note from a donor

[Cym13]

On Wednesday, 25 October 2017 at 23:37:37 UTC, codephantom wrote:
> On Wednesday, 25 October 2017 at 22:46:27 UTC, Adam Wilson 
> wrote:
>> Even .NET Framework and Core forward to the highly vetted 
>> system crypto API's (SChannel on Windows and OpenSSL on 
>> Linux/macOS). If you need RSA crypto in D, pull in OpenSSL. 
>> Period. Everything else is a good way to run afoul of a 
>> security audit, and potentially expose yourself.
>>
>> Phobos could forward to these system provided API's like .NET 
>> does and provide an idiomatic D interface, but Phobos itself 
>> should absolutely and 110% stay out of the crypto 
>> implementation business.
>
> I agree. D just needs an interface to Encryption providers.
>
> I cannot see how anyone would consider anything other than a 
> provider model, for something that is so highly complex and 
> specialised.

While I agree that we are nowhere near being able to safely 
integrate crypto in phobos it is definitely no that specialized. 
Most communicating programs I can think of use crypto in some 
form or another: data encryption of course, but also secure 
random numbers (which we sorely lack atm), signature verification 
(which was the point here), secure communications (I'm talking 
protocol, not encryption here)...

What communicating program doesn't need to guarantee at least the 
integrity of its data not to talk about confidentiality?

We do have some elements in phobos right now (base hashing 
algorithms for example) and I think we could add more without 
falling into crypto hell. Something as simple as a standard 
interface to the system's cryptographically secure random number 
generator (such as /dev/urandom on linux) would be a valuable 
addition.

While there definitely value in not playing with fire we 
shouldn't be dismissing all crypto operations as a whole just 
because we fear the word.