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;
