On Tue, Oct 24, 2017 at 09:20:10AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > A person who donated to the Foundation made a small wish list known. > Allow me to relay it: > > * RSA Digital Signature Validation in Phobos [...]
This is going to be a tricky one. I'm very wary of implementing cryptographic algorithms without a crypto expert on board. It's just far too easy to get a tiny detail wrong, and open up a gaping security hole as a result. Even though we're not talking about encryption per se, all it takes is for a bug to wrongly validate an invalid signature and we have a problem. And even if there are no bugs, there may be (probably many) inadvertent side-channel attacks opened up if whoever writes the code is unaware of them. The other alternative is to wrap around a reputable crypto library like openssl, but that would mean even more external dependencies of Phobos. And we all know how well that went with libcurl, zlib, etc.: people constantly complain about why this doesn't work and why that breaks. If we build Phobos with an external dependency on openssl, say, that means the installer must make sure it finds the right DLL/.so paths, configure the compiler accordingly, deal with possibly multiple incompatible local versions of the same library on the user's system, etc.. But if we ship openssl with Phobos to avoid this problem, then we have another problem: needing to push out a high-priority security fixes if an exploit is published, etc., which currently we simply don't have the infrastructure to deal with. Neither alternative sounds appealing to me. (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. Still, I wouldn't feel confident about a crypto library written in D unless it was reviewed by someone with crypto expertise. Or preferably, *multiple* crypto experts. It's just far, far too easy to get it wrong, with disastrous consequences.) T -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen
