[Cryptography] a question on consensus over algorithmic agility

Arnold Reinhold agr at me.com
Fri Jun 27 15:19:02 EDT 2014


On Thu, 26 Jun 2014 11:33 ianG wrote:
...
> Debunk 3.  Indeed, we have so much confidence in our algorithms that the
> following argument shows we've never taken the 'alg backup' argument
> seriously:
> 
> Take your favourite two block ciphers.  Independent keys, XOR the
> output.  This provides the strength of both, together.  In agile terms,
> it totally dominates the agile argument because it employs both, fully
> at the same time, and it eliminates the negotiation morass.  (Same thing
> can be done with other algs like HMACs).
> 
> Yet, we rarely do that.  We rarely use superior engineering, we always
> fall back to the negotiation approach.  Where I've seen it used is in a
> Dutch cipherphone and I think blockchain technologies used 2 for one
> hashing.  Rare!
> 
> Why?  (a) Because cryptographers teach us that to do this is futile
> because if it was a good idea *they'd already have done it*. (b) many
> would say that to use two algorithms would be a performance hit (never
> mind that they have created a performance uncertainty...) so this shows
> that 'backup alg' argument is secondary to performance.  Which kind of
> puts it in the shade as far as security is concerned.
> 
> In security and software engineering, doubling the cipher totally
> dominates the backup alg argument ... conundrum?  Or debunk.
...

I like your dual encryption argument, but I think it leads to a better solution to the fallback algorithm question:

Choose two independent algorithm suites we currently trust, A and B. The primary protocol will use A. The fallback algorithm will be A super-encrypted with B. If a flaw is found in A, the fallback will have at least the strength of B. But if an attacker knows a weakness in B, there is no incentive for them to force a switch to the fallback.  

The relative inefficiency of the fallback is only a problem in the unlikely circumstance that A is compromised. If that ever happens, we develop a revised protocol with B as the primary, A super-encrypted with B as a transition, and choose a new suite C and make B super-encrypted with C as the new fallback.

(And if there is a weakness discovered in both in A and B, pick a new C and D. One might still allow  A super-encrypted with B as a temporary transition, as  their combination may yet be strong.) 

Outside of some added complexity, I see no security downside with this approach, it's efficient as long as we trust A and it covers the algorithm flaw risk, without the "trust my favorite cryptographers not to make mistakes" argument.

Arnold Reinhold





More information about the cryptography mailing list