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.
