[Cryptography] a question on consensus over algorithmic agility

Jerry Leichter leichter at lrw.com
Mon Jun 30 15:27:13 EDT 2014


On Jun 30, 2014, at 3:01 PM, Phillip Hallam-Baker <phill at hallambaker.com> wrote:
> So the logical outcome of asking for algorithm agility is ... a single more complex algorithm.
> 
> Not really.
> 
> The reason I specify AES as the mandatory to implement algorithm in protocol specifications is that it is the only algorithm currently in use that satisfied all the following criteria:
> 
> 1) Informed option considers the algorithm to be acceptably secure for all encryption applications.
> 
> 2) Is the result of an open selection competition that is generally agreed to have been reasonably transparent and to have made the decision on empirical grounds,
> 
> 3) Is ubiquitously supported on all platforms including hardware.
> 
> A new more complex algorithm would not meet those criteria. But that is OK because my criteria for a backup algorithm are not the same as my criteria for a default algorithm.
I'm responding to John Kelsey's point that a fallback is only useful if you're willing and able to throw the primary away.  You're basically saying that you trust the primary, but will kind of accept the fallback if you're forced to.  Not at all the same thing.  And if that's really how you feel ... many will argue that the threat to the primary isn't really so bad, we aren't really so confident in the fallback, no one's seen an actual break yet ... and you're left in the position that many won't move to the fallback, so you're forced to use the primary you no longer trust in order to communicate with them.

BTW, it's not *a* new, more complex algorithm.  The encode side is given
by:
	w = select_randomly({0,1})
	send w
	if (w == 0)
		send encryption of data using A
	else	send encryption of data using B

I was being a bit facetious about the "more complex algorithm".

                                                        -- Jerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140630/eeefa849/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140630/eeefa849/attachment.bin>


More information about the cryptography mailing list