[147560] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:

daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Mon Oct 7 19:33:09 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <6A6E8D2C-1897-40F9-8174-99453531BC32@gmail.com>
Date: Mon, 7 Oct 2013 15:52:32 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: John Kelsey <crypto.jmk@gmail.com>
Cc: "cryptography@metzdowd.com List" <cryptography@metzdowd.com>,
	Jerry Leichter <leichter@lrw.com>,
	Christoph Anton Mitterer <calestyo@scientia.net>,
	Dirk-Willem van Gulik <dirkx@webweaving.org>,
	Nico Williams <nico@cryptonector.com>, james hughes <hughejp@mac.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============1191716351704471516==
Content-Type: multipart/alternative; boundary=001a11c34e6c2f3cdf04e82bfebc

--001a11c34e6c2f3cdf04e82bfebc
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Oct 6, 2013 at 11:26 AM, John Kelsey <crypto.jmk@gmail.com> wrote:

> If we can't select ciphersuites that we are sure we will always be
> comfortable with (for at least some forseeable lifetime) then we urgently
> need the ability to *stop* using them at some point.  The examples of MD5
> and RC4 make that pretty clear.
>
> Ceasing to use one particular encryption algorithm in something like
> SSL/TLS should be the easiest case--we don't have to worry about old
> signatures/certificates using the outdated algorithm or anything.  And yet
> we can't reliably do even that.
>

I proposed a mechanism for that a long time back based on Rivest's notion
of a suicide note in SDSI.


The idea was that some group of cryptographers get together and create some
random numbers which they then keyshare amongst themselves so that there
are (say) 11 shares and a quorum of 5.

Let the key be k, if the algorithm being witnessed is AES then the value
AES(k) is published as the 'witness value for AES.

A device that ever sees the witness value for AES presented knows to stop
using it. It is in effect a 'suicide note' for AES.


Similar witness functions can be specified easily enough for hashes etc. We
already have the RSA factoring competition for RSA public key. In fact I
suggested to Burt Kaliski that they expand the program.

The cryptographic basis here is that there are only two cases where the
witness value will be released, either there is an expert consensus to stop
using AES (or whatever) or someone breaks AES.

The main downside is that there are many applications where you can't
tolerate fail-open. For example in the electricity and power system it is
more important to keep the system going than to preserve confidentiality.
An authenticity attack on the other hand might be cause...

-- 
Website: http://hallambaker.com/

--001a11c34e6c2f3cdf04e82bfebc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Oct 6, 2013 at 11:26 AM, John Kelsey <span dir=3D"ltr">&lt;=
<a href=3D"mailto:crypto.jmk@gmail.com" target=3D"_blank">crypto.jmk@gmail.=
com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">If we can&#39;t select ciphersuites that we =
are sure we will always be comfortable with (for at least some forseeable l=
ifetime) then we urgently need the ability to *stop* using them at some poi=
nt. =A0The examples of MD5 and RC4 make that pretty clear.<br>

<br>
Ceasing to use one particular encryption algorithm in something like SSL/TL=
S should be the easiest case--we don&#39;t have to worry about old signatur=
es/certificates using the outdated algorithm or anything. =A0And yet we can=
&#39;t reliably do even that.<br>
</blockquote><div><br></div><div>I proposed a mechanism for that a long tim=
e back based on Rivest&#39;s notion of a suicide note in SDSI.</div><div><b=
r></div><div><br></div><div>The idea was that some group of cryptographers =
get together and create some random numbers which they then keyshare amongs=
t themselves so that there are (say) 11 shares and a quorum of 5.</div>
<div><br></div><div>Let the key be k, if the algorithm being witnessed is A=
ES then the value AES(k) is published as the &#39;witness value for AES.=A0=
</div><div><br></div><div>A device that ever sees the witness value for AES=
 presented knows to stop using it. It is in effect a &#39;suicide note&#39;=
 for AES.=A0</div>
<div><br></div><div><br></div><div>Similar witness functions can be specifi=
ed easily enough for hashes etc. We already have the RSA factoring competit=
ion for RSA public key. In fact I suggested to Burt Kaliski that they expan=
d the program.</div>
<div><br></div><div>The cryptographic basis here is that there are only two=
 cases where the witness value will be released, either there is an expert =
consensus to stop using AES (or whatever) or someone breaks AES.</div><div>
<br></div><div>The main downside is that there are many applications where =
you can&#39;t tolerate fail-open. For example in the electricity and power =
system it is more important to keep the system going than to preserve confi=
dentiality. An authenticity attack on the other hand might be cause...</div=
>
<div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">htt=
p://hallambaker.com/</a><br>
</div></div>

--001a11c34e6c2f3cdf04e82bfebc--

--===============1191716351704471516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============1191716351704471516==--

home help back first fref pref prev next nref lref last post