Note from a donor

[Adam Wilson]

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.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;