[Cryptography] best practices considered bad term

[Peter Gutmann]

Watson Ladd <watsonbladd at gmail.com> writes:

>Huh? We know quite a bit about cryptography from actual cryptographers, which
>ignoring lead to exploitable holes.

There's a large difference between *exploitable* holes and *exploited* holes.
Attackers aren't in this to count coup (well, most of them aren't), they're
there to maximise ROI.  How many credit cards or bank accounts were
compromised due to the attacks you mention?  No-one actually knows, but it's
likely to be zero, or close to it, because only an idiot attacker would bother
with CRIME or BEAST or POODLE when you can simply lift a vendor's credit card
database wholesale (imagine explaining to your boss in the Russian mafia "I've
just spent three days implementing BEAST, and then tomorrow I'm gonna steal me
some cookies, that'll show 'em").

In fact lets see what happens when you use really bad crypto.  I'll fire up my
Windows 95 PC and load up Netscape Navigator 3.0 (the first to do SSLv3) and
buy something from Amazon (assuming it still allowed SSLv3 connections) all
secured with the power of 56-bit single DES and MD5.  Absolutely nothing (bad)
will happen.  Well, my Windows 95 PC will get owned within about five minutes
of going online, but the crypto won't cause any problems.

Let's get even sillier and use the closest we can get to worst-practice
crypto, RC4-40 with MD5.  Watch the complete lack of anything bad that happens
(apart from my PC now being a member of twenty different botnets).

Apart from having my PC owned, if anything does go wrong it won't be due to me
using 56-bit single DES or RC4-40 or MD5 or even no encryption at all, it'll
be from someone using SQL injection to steal 20 million credit cards at once
from some online vendor, not a single credit card using BEAST.

(I specifically chose SQL injection there because it remains #1 in the OWASP
top ten.  Bad cryptography doesn't even feature in the top ten).

>We also know that RSA is significantly slower at reasonable security levels
>then ECC, and that AES-GCM outperforms hash-based constructions in hardware
>and now in software on recent Intel processors, while Poly1305 does so across
>a wider range of machines.

This isn't Formula 1 racing where you're in a competition to be the fastest,
it's a binary, or at least shades-of-grey, distinction: "works for me",
"doesn't work for me", and possibly "isn't so good but I can deal with it".
If you're on an embedded system then you may well go with RSA (not ECC)
because client-side it's much faster than ECC.  OTOH if you've got CPU
power to spare (which a great many devices have) it doesn't matter what you
use because, well, you've got CPU power to spare.

Peter.