Caveat: I’m not a cryptographer, so please don’t take my comments below as being anything more than wild noodlings. That said…
I’m getting tired of helping to deal with the fallout produced by the last few years’ parade of cryptographic attacks on SSL/TLS (BEAST, LUCKY13, RC4, POODLE, …) and, as an amateur student of the fields of system safety and planning, I’d like to see a conversation about trading some money for better design-time assurance about the resiliency of the cryptosystems we’re now designing to the future discovery of flaws in our underlying cryptographic primitives.
Thus: in parallel with using fancy mechanisms to negotiate which ciphers to use to protect our communications, can we also specify a ciphersuite that is intended to be resilient to primitive design flaws even at the cost of some CPU time or required hardware footprint perhaps by combining \(k\) independently-designed primitives in a way that we believe will tolerate \(k-1\) primitive design mistakes?
Next, as to an early step in the direction of this design concept, let’s look at one typical objection (of which there are several to overcome), which is
It’s hard to compose block ciphers in a way that gracefully tolerates the failure of individual block ciphers.
As for next steps:
Please forgive my ignorance, but why is this actually hard? (That is, “What is the actual obstruction?”)
Does this obstruction also apply to the following construction?
If so, cool! (In particular, thanks for helping me to better understand why this is hard!)
If not, then what are some of the other objections that I would need to help deal with in order to further advance this design agenda?