[Cryptography] quantum computers & crypto

Jerry Leichter leichter at lrw.com
Sun Oct 31 12:50:23 EDT 2021


> Software ought to have three to seven algorithms, at most, built in.  No
> plugin anything, plugins are an attack surface. Not even any use-time
> negotiation among those algorithms; they're strictly ordered, become
> unavailable when decertified, and the software always uses the first
> available.  If all those algorithms have been de-certified, that
> program, or at least that version of it, has reached the end of its
> useful life and ceases to work, period.
> 
> Ideally that's implemented as contagious de-certification - with some
> form of accepted, certified proof that the de-certification is real. 
> Refusing the current "standard" algorithm requires showing proof of
> de-certification to prevent it from being spoofed, and having seen that
> proof the other party to the connection must immediately start refusing
> that algorithm flatly, roll forward to the designated "next"
> still-certified algorithm, and showing the de-certification proof to any
> contactee that attempts to use it.
I see two problems with this approach:

1.  If some of the three to seven algorithms are known - or at least strongly believed - to be stronger than the others ... why include the weaker ones?  But if they are all (as far as we know) equally strong, then an attacker might break any one of them at any time.  If it happens to be the one currently in use ... good times for them.  If it's one of the others ... you've just created a huge incentive for the attacker to try to force a roll-forward to the algorithm he has an attack against.  Just what looks like a partial attack, or even just rumors of an attack, will likely be enough for some users to decide, in the famous abundance of caution, to roll forward - right into the ambush.

2.  Just what would constitute a sufficient proof of decertification?  Is is a signed note from a bunch of pre-accepted authorities attesting to a problem?  Signed with what algorithm:  The current one, so that you get a message using a particular algorithm asserting that the algorithm is no good?  Oddly, that kind of works ... but it seems very peculiar.  If not that ... then what?  Signed using the *next* algorithm?  Or one of the other "future" algorithms?  That falls right into the ambush of the previous item!  Signed using some other algorithm?  Does it have to be stronger than any of the seven?  If so, why aren't you just using it?

I agree that there's something very tempting about this approach.  Actually, I've proposed a broader application of a simpler version for trustable hardware/software:  You build a secure kernel that's so simple that you can really prove it secure *and never allow any patching.*  A patch mechanism is a potential attack vector, and one that immensely opens the potential attack surface.  Leave it out.  If it turns out you got it wrong, replace the whole thing with a new one designed along similar principles.

                                                        -- Jerry



More information about the cryptography mailing list