Note from a donor

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Oct 25 18:23:50 UTC 2017


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

-- 
You have to expect the unexpected. -- RL


More information about the Digitalmars-d mailing list