[cryptography] ICIJ's project - comment on cryptography & tools

Kevin W. Wall kevin.w.wall at gmail.com
Sat Apr 6 13:28:30 EDT 2013


On Sat, Apr 6, 2013 at 7:34 AM, ianG <iang at iang.org> wrote:
> On 6/04/13 07:27 AM, Nico Williams wrote:
[snip]
> This bit:
>
>> We hope the NSA types haven't forgotten that good guys
>> need crypto, whether LEA like it or not.
>
> I personally believe that the NSA's policy that the good guys don't need
> good crypto is the underlying root to the problem.  A goodly portion if not
> all.
>
> Internally to the NSA this is known as 'the equity issue' or so I've heard.
>
> In economic terms, the NSA imposes a sort of tobin tax on crypto which
> results in a stupidity drag on all security, thus making it easier for all
> to avoid doing good work.
>
> Otherwise, I can't answer the question -- why as a society are we so good at
> internets, databases, apps, social networks, distribution of institutions,
> algorithms, all the good CS stuff, but we can't get our collective security
> act together?

I think you're giving the NSA way too much credit on why security sucks.
Even if we were to restrict 'security' to the scope of cryptography, even
there, I think the NSA has much less to do with dumbing down crypto
security than other factors. IMO, the biggest factor is that 95% or more
of developers are completely ignorant of best practices in cryptography.
They good to some security book or beginning crypto book and emulate
the first example that they see which is using something like AES with
ECB mode and no padding and they copy it. Done. Cross that off their list.
When I've spoken to them, they aren't even aware of what cipher modes
are let alone why they should be using authenticated encryption! I blame a
lot of that on API design. Great example of poor design is Java's JCE.
It exposes cryptographic primitives as the expected low level that developers
want to deal with where what the really need is a much higher level API.
Furthermore, the defaults in JCE are just wrong (e.g.,ECB mode with no padding,
no authenticated encryption modes supported in the reference SunJCE
implementation, etc.)

However, the real reasons that security sucks goes way beyond crypto. In fact,
only a small part of application security has to do with crypto. As
has been repeated
several times on this list, even bad crypto is seldom the weakest link.

And I don't even believe that the root cause for poor security is even developer
ignorance or apathy. Most developers want to write code that is secure. The
reason they don't is that it is just not a priority for them. There
are two things
that I think are fueling our poor application security. The first is,
that the sponsoring
business units see not value per se in building systems that are secure nor even
maintaining secure systems (e.g., through regular patching and operational
reviews, etc.). They typically see security only has an additional
cost that contributes
nothing to their bottom line.  Because of that they are not willing to provide
additional budget nor additional time in schedules to bolster security. This
also somewhat explains the developer crypto ignorance in that they seldom are
willing to fund developers to be trained in application security,
including applied
cryptography.

Second, but somewhat related to this, is that developers are not rewarded
for developing secure designs and/or writing secure code. They are rewarded
for writing efficient and fast code that reduces hardware needs (thus
lowering costs)
and for writing fault-tolerant code (thus reducing outages and
increasing availability),
but it is rare to see anyone *rewarded* for writing secure code. (Note
that the reverse
may be true though...developers may be punished [through dismissal,
etc.] for writing
really bad, insecure code, especially if the organizational culture is
to find a scape
goats when a security breach is discovered.)  In many ways it is even
very difficult
to identify those who write secure code; it is much easier to identify
those who write
insecure code. Generally, only the test of time helps identity those
who regularly
produce secure code, but because it takes so long, there is no near
term feedback
and those developers are not rewarded for it. Consequently, it is not
a priority with them.

Note that these are only observations that I've seen that have been
consistent through
all the places where I've been employed. YMMV, but I expect there will
generally be
more similarities than differences.

Just my $.02,
-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein


More information about the cryptography mailing list