[Cryptography] a question on consensus over algorithmic agility

[Tom Mitchell]

On Mon, Jun 30, 2014 at 9:41 AM, John Kelsey <crypto.jmk at gmail.com> wrote:

> > On Jun 27, 2014, at 9:32 AM, Peter Fairbrother <zenadsl6186 at zen.co.uk>
> wrote:
> ...
> > I was almost convinced, for a moment. Two or maybe three suites, only
> SHALLs allowed, so there is no question of whether a suite is installed or
> fit for purpose - sounds good.
> >
> > But who decides when to stop using an algorithm suite?  The luser
> client? The boss server?
> >
> > It's certainly not the cryptologist.
>
> I'm working on the assumption that the knowledge that a given ciphersuite
> has problems will, in fact, get around and eventually lead to people being
> willing to turn off one of the ciphersuites,



This is an ancient problem.

Shared libraries was one solution that does not work for embedded hardware
or languages
like Google's GO.  Deprecation of bad ideas including bad code is a human
issue involving communication.
Correct tool in the correct context... same tool in a different context is
all wrong.

It is not just crypto the same issue is at the heart of some of the
anti-vaccer problems
where an authority declared that he had scientific proof that autism and
vaccines were linked.
We now know that he invented the data out of thin air and all the research
built on
it and all the laws built on it are wrong.  Some might be correct for the
wrong reason.

For cryptographic topics there is a chain of issues that need to be
considered
for the code.

1) simple bug... once fixed at both ends all is good.
1a) an alternate path is needed while the fix is deployed.
2) key generation bugs... fix the bug, generate new keys and invalidate the
old.
3) total blunder -- it does not work and must be abandoned.
4) compromised in unknown ways...

Other issues need to be considered in the context of deployment.

A) can it be audited in use?
B) can it be subverted?
C) can it be used in ways invisible to audit?
D) does it bypass normal inspection?
E) does use invite scrutiny?
F) can policy be enforced or enhanced at a firewall?

I recall the ssh bug where secure shell was
so broken by a bug now fixed that telnet with passwords
in the clear was more secure. Once the server
side bug was fixed system admins could reboot after
enabling ssh again and close down telnet with a window
to transfer new keys as needed.

As the above ssh bug decades ago showed some agility is needed.
Agility can be administrative or automated.

As the arrest of Eldo Kim at Harvard demonstrated as one
of six that used TOR simply using a tool invited scrutiny.

Agility is only one issue.   Consider HTTPS with multiple
keys and multiple algorithmic methods under the hood.
If the likes of Google, Amazon, bsd.edu discover a problem
they can turn one off and leave the other in play.  If agility
is involved the issue is invisible.

Invisible adaption is both good and bad.  At some point it must trigger
resolution and communication but not zero day exploits.
Adaptive code can trigger randomly or trigger on command.
It is not just code,  key selection and use needs to be adaptive
as central key repositories can be hacked.  A central repository
is a single point of failure.  Is agility good or bad here. Does
agility open or close exploit doors.

In my mind.... "use invite scrutiny" is a critical path topic.


-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140630/30e15591/attachment.html>