[Cryptography] asymmetric attacks on crypto-protocols - the rough consensus attack

[Ray Dillinger]

> On 8/5/15 1:25 PM, John Kelsey wrote:
>> I wonder what fraction of the time people invent their own crypto
>> algorithms and protocols, and the result is better than the standard
>> stuff.  I'm guessing the fraction is small enough that it needs quite
>> a few significant digits to be distinguishable from zero.

I'm guessing only around three significant digits.  A lot of
programmers are actually both conscientious and smart.  More
than one out of a thousand will actually do the research and
the homework and do a good job of protocol design.

Cipher or RNG design I'm less sure about.  It seems that people
invent three of these a week and I've essentially never heard of
anybody other than a math/crypto pro or a university researcher
inventing ANYTHING in that line that there is a good reason to
use.  Rarely, one of the better ones is secure AFAICT, but none
so far are both secure AFAICT and have any other advantage over
existing and well-examined secure algorithms.


On 08/05/2015 10:01 PM, David Johnston wrote:

> Many standards (e.g. from IETF, IEEE 802 (before they learned to stop
> asking the government for help), SP800-90, X.509 etc. ) have proven
> toxic, either cryptographically, structurally or in terms of
> implementation complexity. 

This is true.  But it is true any time software is designed by
committee.

If one is trying to write one's very first crypto application,
I think designing with the specific goal of compliance with
any standards over about 10-15 pages long is likely to cause
enormous numbers of bugs.

The committees do not tend to produce anything simple enough to
fully understand all at once.  The usually-good programmer habit
of breaking things into subproblems and thinking about them
separately does not work well in this case.  In fact it is, in
crypto software, possibly the primary origin of most serious
failures. MANY attacks are perpetrated by using "distant" parts
of the system together whose interaction the programmer (or
sometimes the committee whose standard the programmer was
slavishly following) never considered. Fewer moving parts would
be fewer opportunities for that to happen.

So I'm with David here.  Standards are good design input but
mainly in terms of reminding you of the attacks that the standards
are designed to defend against.  If you read them merely as
instructions on how to build something secure, you will fail.

Design it carefully.  Then build it.  Be sure it's working as
designed.  Then if and ONLY if you can do it without compromising
the design, see if you can actually comply with those standards
without breaking its security.

If you can't, then either the standard does not describe what
you intend to do and need your software to do, or it was a bad
standard and you shouldn't be following it anyway.  In fact
in the case of a bad standard, following it slavishly to be
interoperable with all the other things that follow it, is
simply adding your application to a pile of toxic waste that
will eventually have to be cleared away for the sake of public
safety. (X.509 CA process, I'm looking at you....)

> Standards are a minefield. We need to learn to tread carefully.

Indeed.  And that includes conscientiously not implementing any
which you know to be bad, insecure, inappropriate for your
specific application, or have too many details to hold in your
head all at once.  Sometimes standards documents are inapplicable,
dangerous, or just plain wrong.

			Bear




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150806/58ff41d5/attachment.sig>