Note from a donor

[rikki cattermole]

On 25/10/2017 11:46 PM, Adam Wilson wrote:
> On 10/25/17 11:23, H. S. Teoh wrote:
>> On Wed, Oct 25, 2017 at 08:17:21AM -0600, Jonathan M Davis via 
>> Digitalmars-d wrote:
>>> On Wednesday, October 25, 2017 13:22:46 Kagamin via Digitalmars-d wrote:
>>>> On Tuesday, 24 October 2017 at 16:37:10 UTC, H. S. Teoh wrote:
>>>>> (Having said all that, though, D is probably a far better language
>>>>> for implementing crypto algorithms -- built-in bounds checking
>>>>> would have prevented some of the worst security holes that have
>>>>> come to light recently, like Heartbleed and Cloudbleed.
>>>>
>>>> Those were buffer overflows in parsers, not in cryptographic
>>>> algorithms.
>>>
>>> The point still stands though that you have to be _very_ careful when
>>> implementing anything security related, and it's shockingly easy to do
>>> something that actually leaks information even if it's not outright
>>> buggy (e.g. the timing of the code indicates something about success
>>> or failure to an observer), and someone who isn't an expert in the
>>> area is bound to screw something up - and since this is a security
>>> issue, it matters that much more than it would with other code.
>> [...]
>>
>> Yeah.  There have been timing attacks against otherwise-secure crypto
>> algorithms that allow extraction of the decryption key.  And other
>> side-channel attacks along the lines of CRIME or BREACH.  Even CPU
>> instruction timing attacks have been discovered that can leak which path
>> a branch in a crypto algorithm took, which in turn can reveal
>> information about the decryption key.  And voltage variations to deduce
>> which bit(s) are 1's and which are 0's.  Many of these remain
>> theoretical attacks, but the point is that these weaknesses can come
>> from things you wouldn't even know existed in your code. Crypto code
>> must be subject to a LOT of scrutiny before it can be trusted. And not
>> just cursory scrutiny like we do with the PR queue on github; we're
>> talking about possibly instruction-by-instruction scrutiny of the kind
>> that can discover vulnerabilities to timing or voltage.
>>
>> I would not be comfortable entrusting any important data to D crypto
>> algorithms if they have not been thoroughly reviewed.
>>
>>
>> T
>>
> 
> I am one-hundred-ten percent in agreement with Mr. Teoh here. 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.

Or mbedtls who has also been audited (but much better and nicer code!).
Either way, you write it, you pay for auditing or no users. Hence I 
won't use our port of Botan.