[Cryptography] What is a secure conversation? (Was: online forums...)

Theodore Ts'o tytso at mit.edu
Mon Dec 30 11:06:11 EST 2013


On Mon, Dec 30, 2013 at 08:52:43AM +0300, ianG wrote:
> 
> Threat modelling is separated because the threat is the domain of
> the attacker, whereas the risk is the domain of the defender.

Even in the domain of the attacker, the attacker is attacking a
*specific* protocol, being used in a *specific user case*, and to
achieve a *specific* goal.  If we are going to accurately model a
threat, we need to understand these specifics.  Unfortunately, I don't
see that happening in many of these discussions on the mailing list.

For example, the people worrying about cache timing attacks for a KDF.
OK, but in what protocol or application is the KDF being used?  What
most of the cache timing attacks require an oracle where the attacker
can feed many different versions of the plaintext and ciphertext, and
then can measure the difference in timings for different
paintexts/ciphertext being encrypted/encrypted.  Given that many KDF's
are used to transform a password typed by the user into a key, what's
the scenario where a cache timing attack on KDF be applicable?

And yet, there is a whole thread, and people proposing changes to
algorithsm, to address this threat, without any kind of filtering
about whether it is a credible threat.

> >Personally, part of talking about listing the threat also includes
> >doing the risk analysis, because otherwise the list can easily become
> >unbounded, and because there are people who are overly inclined to
> >paranoia will start pursuing solutions and demanding that we make
> >changes to mailing lists, protocols, open source software, etc.,
> >prematurely.
> 
> Right, and that is why every listed threat has to be filtered.  In
> risk analysis, they do teach you to do a preliminary pass and drop
> stuff that is on the face of it unrealistic (at least in my class
> they did).

Great.  But that is not what is happening for most of the discussions
on this mailing list.  There is no attempt to make sure that the list
is complete, and there is no attempt to filter the threats for
credibiity.  Instead, people immediately start leaping to proposed
solutions and wringing their hands that all of our crypto applications
are broken....

> Another threat that we should consider in our list:  what happens if
> there is an insider in *our process* that has interests that are
> incompatible with ours, and pushes us to weaken our process (and
> improve his)?

I'm not sure that this is ever going to be productive.  Sure, it's
possible, but the solution is open proposals, open source, and open
peer review.  Otherwise, I could start complaining that people who are
ranting and raving about threats without doing any kind of filtering
are NSA plants who are trying to waste/disapate our energy, and you
could claim that I'm a NSA shill for refusing to pay attention to your
favorite pet threat.  And in the end, it doesn't further the
discussion, but in act, degrades it.

> We know what doesn't work:  committees, broad-based low-level crypto
> tool analyses, government standards, consultancies.
> 
> What that leaves is, I think:  the business must appoint one person
> to take responsibility.  That person must make the decision to drop
> the unrealistic threats, once they've had their day in the sun.

Who is "the business" and why do they get to decide who to appoint?
How does this apply to all of our open source technologies, such as
OpenSSH, OpenSSL, the Linux /dev/random driver, etc?  In the case of
the RSA business, they chose Bart Harman as their CTO, who is
presumably "the decider".  Given his recent statements, does that make
you feel any more comfortable?

Committees do have their downsides, but at least we're not depending
on a single person.  Annointing a single person means that there is a
single point of failure where that person might make be bribed or
otherwise corrupted, or just make a single mistake.

And that person may make take on all of the successes and failures,
but to the extent that we depend on that technology, and we don't have
the time to audit all possible security technologies, or to write all
of the securiy technologies (and all of their dependencies, including
the Intel CPU for those people who believe that the NSA could subvert
the instruction pipelining and execution engine), we don't have a
choice but to delegate our security to some set of people, or a single
person.  Personally, I'd much rather delegate my security to an open
committee using an open process.

Regards,

						- Ted


More information about the cryptography mailing list