[Cryptography] quantum computers & crypto

[Ray Dillinger]

On 10/31/21 6:10 AM, cherry wrote:
> On 10/30/21 3:03 PM, Ray Dillinger wrote:
>> Certs with keys for multiple algorithms allowing
>> quick,easy,transparent upgrades if an algorithm is decertified.
>
> Lets not.
>
> So many things are broken or backdoored, and multiple algorithms means
> more places for things to be accidentally or maliciously broken.
>
And yet they need certs that will continue to work when we YANK THOSE
DECERTIFIED SIGNATURE ALGORITHMS OUT FROM UNDER THEM.  Algorithm
decertification should not be customer decertification.  It can't be
allowed to kill more than one customer cert in ... fifty thousand maybe?
If it's more than that, we already know that people given a choice will
refuse to allow the decertification process to work.  So they need certs
that will survive a half-dozen algorithm decertifications.  And just as
importantly they need to not be responsible for making any choice of
whether the decertification process works.

You have articulated exactly the problem.  We have been beaten over the
head with painful and expensive experience about giving people algorithm
choices.  But in the QC world I fear we will have to be able to make
rapid switches to new algorithms due to frequent discoveries about
insecurities in the ones we're using.

We must do it WITHOUT giving the attackers (and therefore users) choices
to make, and WITHOUT exposing more than one algorithm's worth of "attack
surface" at a time.

Experience is the best teacher, but she commands a very high price.  We
cannot afford to repeat her lessons.  Listen to me, I'm an Old Phart who
learned at her knee.  And I learned we must not do it that way.

It is very much the case that algorithm agility in which the attackers
were given choices was a disaster.  Of course they made every choice
maliciously.  What did anyone expect? What part of "attacker" did we
frick'n miss?   We were so god damned stupid.

It is very much the case that the availability of multiple algorithms
and giving the choice of them to people who lacked any appreciation of
the meaning of those choices was also a disaster.  Lots of them just
tinkered until they "got it working" and then never touched it again.
They fought *HARD* to give their money and secrets away, insisting that
no matter how broken something was it couldn't be removed because then
they'd have to tinker and "get it working" again, which is apparently
way more difficult than screwing over the security of every user in the
world by allowing stinking abominations to remain in play.  The
combination of stinking abominations never decertified, and the protocol
still giving attackers choices which can include the stinking
abominations, is the dumbest possible combination.

And yet Post-QC will require *some* algorithm agility because the math
and practice and hardware aren't mature.  It's a whole new world in
which new discoveries will be made for at least decades.  And some of
those discoveries will invalidate algorithms we thought were secure.  It
will take decades to get a real handle on the possibilities and
limitations, and until that time people responsible for the security of
any particular application need to be able to take things *out* of use
in that application, at any time.  But none will ever be ALLOWED to take
things out of use, if users are allowed to make algorithm choices,
allowed to ignore de-certs, or allowed to prevent automatic failover to
something else.  In short, the attackers must be allowed no choices to make.

We will never be allowed to decertify something unless we can do it
instantly, automatically, universally, irrevocably, permanently, without
warning, and painlessly.  The users of a given program don't get choice
to screw up; they get a brutally simple automatic selection that's
already made for them, plus automatic failover to the next when a
de-certification arrives.

We don't want committees.  We don't even want the users' input.  If we
ask for it the attackers will tell us to give them choices.  Because
acres of shit can be hidden in choices, because malicious crap can be
added to the set of choices later, and because whenever users make
choices the attackers can lead them to make bad ones.

Bear