[Cryptography] best practices considered bad term

[Watson Ladd]

On Sun, Feb 1, 2015 at 6:44 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> ianG <iang at iang.org> writes:
>
>>As a wider philosophical question, is it even appropriate to promote or
>>accept 'best practices' in the security world?  It's presence is almost a
>>complete proof that we're not doing security, we're instead participating in
>>a rain dance or voodoo for purposes of avoiding security.
>
> This is particularly the case for the "cryptography" subset of "security", for
> which "best practice" seems to be synonymous with, as Linus put it, "people
> wanking around with their opinions".  In something like medicine we have
> evidence-based best practice, "don't discontinue your antibiotics until you've
> gone through the full course".  In agriculture we have "don't overuse one type
> of fungicide or you'll end up with resistant strains".
>
> In contrast in crypto it's "Use ECC!" / "No, use RSA with an 8K key!" / "No,
> use AES-GCM!" / "No, use Poly1305-AES" / "No, use ECC but only with My Pet
> Curve!" / "No, use Ed25519" / "Camellia! Gost! Twofish! SEED!  LIONs and
> Tigers and BEARs, oh my!", ignoring the fact that an attacker won't care what
> you do since they're exploiting a buffer overflow in some ancillary support
> library that you don't even know exists.

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

-Statistical problems in RC4 output resulted in stealing cookies.
-The need for randomization of CBC inputs->BEAST
-The need for formal models of key negotiation->Triple Handshake, the
renegotiation vulnerability,
-The failure of generic security for MtE->Lucky13, POODLE, the SSH
equivalents, XML encryption vuln
-PKCS 1.5 encryption->periodic bugs in TLS implementations
-SPA and DPA/timing attacks
-Failure to validate input points -> problems all over the place


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. Of course, this is
all covered with a level of BS from people who aren't cryptographers.

>
> In medicine and agriculture we know from real-world experience that if you
> don't follow best practice (in the use of antibiotics, fungicides, whatever),
> bad things will happen.  In the crypto world if you don't follow best practice
> (pick someone's at random, it doesn't make much difference) chances are
> nothing will happen, and even if you do follow best practice, you'll probably
> get owned anyway because crypto won't stop anyone who wants to get in (see
> Shamir's Law, what I mean here is that if there's a way in then it won't
> involve breaking the crypto, an extended form of which is in this slightly
> NSFW poster: https://www.kiwicon.org/site_media/poster_shit.pdf).

Explain why Flame needed to use an MD5 collision then. Or how about
"pass-the-hash"? What about the poor random number generation in
Android leading to bitcoin thefts through Bleichenbacher attack? Or
all the attacks on OpenSSL in shared hosting environments (think AWS)
with key recovery as the bottom line?

The NSA is exploiting IKE v1 Aggressive mode with PSK.

>
> So it's certainly a rain dance, but I wouldn't say it's for avoiding security,
> it's for avoiding liability, a la "no-one ever got fired for buying IBM".

Has any software bug ever resulted in liability for the vendor? I
don't see companies rushing out to stop writing network servers in C,
even though we all know that writing them in Java, Go, or Ada would
make buffer overflows unexploitable.

Sincerely,
Watson Ladd
>
> Peter.
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin