Cryptography and D

[Nick Sabalausky via Digitalmars-d]

On 7/5/2014 5:10 PM, Walter Bright wrote:
> On 6/29/2014 1:12 AM, Brad Roberts via Digitalmars-d wrote:
>> A safe rule of thumb with crypto code / libraries:  If the thought of
>> writing
>> that type of code doesn't scare you for at least a dozen or so
>> reasons, you
>> don't know enough to tread in that playground.  Or you're one of the
>> damned few
>> people on the planet qualified and are already working on one.
>
> In a way, it's a bit like writing FP math functions. If using a college
> calculus book as an implementation guide, the results will be
> algorithmically correct but quite wrong, as FP doesn't behave like math.
> Getting them right is something that PhD's in comp sci do.
>
> Crypto takes that and squares the difficulty.
>

Inaccurate comparison.

First of all, FP math is an approximation of "true" real-number 
mathematics. But crypto algorithms (at least any of the ones I've seen, 
and definitely the ones I've implemented) are based on the same discrete 
integer math used by computers and low-level code. NIST's docs even go 
out of their way to formally describe all the nuances of the operations 
their algos use which, surprise, are identical to CPU integer arithmetic 
(at least x86 anyway, I'm not well-versed on ARM but I'd be very 
surprised if it's really *that* different).

Secondly, if the difficulty you're referring to is all the various 
side-channel attacks (like buffer overflows, timing attack, etc), then 
you're conflating crypto and security. The two are certainly related, 
but they are NOT the same. These "side-channel attack" issues are NOT 
something specific to crypto code, they are equally applicable to *all* 
code that has security-related implications, which includes FAR more 
than just crypto. It goes all the way up through application-level code, 
and even into system administration. Implementing a crypto algorithm is 
(comparatively speaking, of course) the "easy" part.

> If someone wants to learn about crypto by writing crypto libraries in D,
> I'm all for it.
>
> But I'm not willing to make those part of the official D repository,
> with its implicit endorsement that people could rely on them for
> critical applications such as, say, banking transactions.
 >
 > What we can do is simply provide a D interface to existing, vetted C
 > crypto libraries. The Deimos project is a fine place for those.

With respect: Oh hell no. No, no, no no no.

1. As others have already said, C is terrible for security libs. Even if 
D isn't ideal, it's still vastly better.

2. Just because a C-based crypto lib is popular and well-regarded 
doesn't mean it's as secure and reliable as people think. See what 
others here have said about OpenSSL (hint: Heartbleed is just *one* of 
the issues).

3. Too late anyway: See std.digest. Besides, if anything, std.digest is 
arguably *worse* because (until 2.066) it only provides the worst 
choices. std.random isn't much better. Granted, it doesn't claim to be 
crypto-grade, but it doesn't clearly state that it *isn't* and that's 
just as bad: People are going to to decide (incorrectly) they can use it 
to generate salts or tokens or whatever, and they will do so. Heck, 
*I've* even done it, and *I'm* someone who actually knows better.