[Discuss] Good and Bad Crypto

[tmetro+blu at gmail.com (Tom Metro)]

Richard Pieri wrote:
> Mike Small wrote:
>> No static analysis tools, no runtime memory debuggers, no discussing 
>> the problem and the general code quality in public forums...
>  
> None of these told us about the Heartbleed flaw in OpenSSL. As a matter 
> of fact, it was Codenomicon attacking their own servers that lead to the
> world-wide revelation. Black box testing worked...

Incorrect.

About 45 minutes into this podcast:
http://www.youtube.com/watch?v=uMjJjBSxiaA

Steve Gibson discusses the timeline of the Heartbleed discovery. Google
researchers, presumably examining the code, found the problem several
weeks prior, and submitted patches to OpenSSL and fixed their own servers.

It was somewhat coincidental that Codenomicon independently discovered
the same problem through black-box penetration testing and announced it
right around the time that Google was making the problem public. (It's
speculated that neither of these were purely coincidental. There is a
very good chance that Codenomicon picked up rumors from the community
that there might be a problem in the area of the heartbeat code, which
directed their testing, and the timing of Google's public announcement
was likely precipitated by the CVE filed by Codenomicon.)


> ...where open source philosophy utterly, completely, catastrophically 
> failed.

(Sometimes I wonder why you subscribe to this list. Having a skeptical
view of things is good, but you seem to take glee in perceived failings
of the open source community, which tends to raise the questions of why
you choose to participate in it and use open source tools. It's almost
as if you are hedging your own bets and deciding to use open source
despite your confidence that it is a loosing strategy. Have more
confidence in your convictions. Make a clean break, if that's your belief.)

Your statement here is akin to saying that "he died when he slammed into
a brick wall at 100 MPH, therefore airbags clearly don't work."

Eric Raymond has a decent essay on why Heartbleed doesn't exemplify a
failing of the open source philosophy:

Does the Heartbleed bug refute Linus's Law?
http://esr.ibiblio.org/?p=5665

Also relevant:

Heartbleed Exposes a Problem With Open Source, But It's Not What You Think
http://mashable.com/2014/04/14/heartbleed-open-source/


> The Heartbleed fiasco is a perfect example of how being open source
> does not magically make the code "better".

You may have heard that elsewhere, but I don't think anyone here has
made that claim.

Being open source doesn't "magically" accomplish much of anything. It's
is merely a necessary precondition for determining that crypto is
trustworthy.


> Mike Small wrote:
>> How do you examine closed source crypto?
> 
> That's both simple and not so simple: you compare what should be 
> deterministic results, and you look for deterministic results when there
> should be none. In other words, you attack the closed cipher or hash 
> implementation of an algorithm the same way you would attack an open 
> source implementation of that algorithm. 

That's a simplistic understanding of how crypto algorithms work. An
algorithm might consist of multiple layered state machines, and
triggering a flaw might require hitting upon a state that your
randomized black-box testing might find only once in a thousand years.

(And that's assuming an unintentional flaw. Intentional backdoors could
require states as unique as the uniqueness of long, high quality random
number, that could take tens of thousands of years of testing to hit
upon. State variables could also come from sources other than the input
keys and data. They could trigger on machine hardware (GUID), time,
date, or data retrieved from the network.)

Source code analysis has the potential to find these, if the code is
analyzed. Back-box testing will find them only if you are very lucky.


Edward Ned Harvey (blu) wrote:
>Tom Metro writes:
>> A cloud storage service should have these characteristics:
>> ...
>> 2. use fully open source client code. If developed by a
>> commercial entity, then there should be an independently
>> developed open source client available.
> 
> If you distribute the client open source, then there's nothing
> preventing someone from developing an open source server to go along
> with it, thus undermining your business model.  There are plenty of
> solutions for which the open source business model doesn't hold.

There are numerous open source businesses that effectively follow the
same model - give away all the code - and are still profitable.

A weak company competes by locking customers into their service. A
strong company competes by giving their customers a reason to *want* to
keep buying service from them.

The scenario you describe is no different than commodity web hosting.
There are hundreds of companies I can turn to who run open source Apache
web servers and will sell me functionally equivalent service. Yet plenty
of these companies are successful, profitable, and find ways to
differentiate.

We should all want to see cloud storage be fully commoditized, so as
consumers we have plenty of choice and low prices. There is still lots
of room for companies to differentiate, such as performance,
reliability, support, and tangential services (like sending you a hard
drive containing all your backed up data by overnight courier, if you
need to recover from a disaster).


>> Uses closed-source, proprietary software. Nullifies the first
>> point.
> 
> Disagree. Both windows and mac are closed-source OSes, which provide
> standard crypto libraries to the application layer.  The fact that
> your OS is closed source immediately nullifies your above
> nullification argument, because it's literally impossible for you to
> run a completely open source stack, unless you switch to a different
> OS.

True. But naturally I wasn't considering that scenario, as I don't use
encryption tools on a proprietary OS. My requirements for a cloud backup
service/tool were just that - *my* requirements that made sense for my
intended usage scenario.

I'd still consider it an improvement, even on a proprietary OS, if your
crypto tool is open source. And better that it bundles a well tested
open source crypto library than rely on a closed source library supplied
with the OS.


> To encrypt files or communications, using standard RSA, ECDH, SSL,
> AES libraries, it literally makes no difference if you're using open
> source or closed source libraries.  Because they're functionally
> equivalent.

Using a proprietary library that implements an open *standard* is way
better than one where the developer decided to roll his own crypto
algorithm. But it is still not the same as having an actual open source
library. (See above on black-box testing.)


> In open source, Truecrypt is one of the appalling ones.

The first half hour of the video I linked to above discusses the initial
report released after starting the audit of Truecrypt. The good news is
that they haven't uncovered any egregious flaws. The bad news is that
they've barely scratched the surface. They have a long way to go, and it
won't be cheap.


> Crypto random numbers...
> I distrust the OS crypto rng in every platform that I develop on.
> Particularly Windows, Linux, Mac.

If you want crypto quality random numbers that the NSA can't monkey
with, use a hardware random number generator. Google and you'll find
lots of options.


> Never send your password to anyone.  Not even a secure trusted server
> on a secure communication channel.  This logically reduces to only 2
> possible solutions:  You must either use a clientside random secret 
> manager, which requires that you transport it around with you 
> somehow, or you use authentication techniques such as asymmetric 
> algorithms, to verify your identity without exposing information 
> about your secret.

BLUer Joseph Guarino shared on G+:

The plot to kill the password
http://www.theverge.com/2014/4/15/5613704/the-plot-to-kill-the-password

which talks about using biometrics in conjunction with a technique
called Zero-Knowledge Proof, which allows you to retain the details of
your biometrics on your local device, yet still use it as a means of
authentication with remote services.

Then there is Steve Gibson's SQRL approach to this;
https://www.grc.com/sqrl/sqrl.htm

Yet to be seen if that will amount to anything.

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/