[Cryptography] quantum computers & crypto

Peter Gutmann pgut001 at cs.auckland.ac.nz
Tue Nov 2 07:23:03 EDT 2021


cherry <cherry at cpal.pw> writes:

>Why is everything created by a committee, and approved by a committee,
>broken, stays broken, and is never decertified?

You know, you could just come out and say "IPsec" here.  It's astounding that
after twenty years of causing pain and suffering it still hasn't been taken
out behind the woodshed and put out of everyone's misery.  Even today the
strategy for setting up IPsec with equipment from different vendors seems to
be to either to turn as much stuff off as you possibly can until you get to a
minimal interoperable feature set, usually barely safe if not explicitly
unsafe, or to keep tweaking parameters on both sides until you can connect
without either your patience or the customer's willingness to keep paying
running out.  It's not like we haven't had WireGuard as a replacement for some
time now.

Another I-can't-believe-we're-still-doing this is RADIUS, or at least UDP
(which fragments and is unreliable so you need to hand-kludge a sort-of
reliability later over it) carrying RADIUS (which fragments and has an open-
ended number of critical protocol-affecting attributes piled onto it) carrying
EAP (which fragments and has an open-ended number of critical protocol-
affecting attributes piled onto it) carrying EAP-TLS or similar carrying TLS
(which fragments and has an open-ended number of critical protocol-affecting
attributes piled onto it) carrying more EAP or PEAP (which fragments and has
an open-ended number of critical protocol-affecting attributes piled onto it)
carrying the actual authentication protocol.  That's seven layers, five to six
of which fragment and have complex attribute handling, all without getting OSI
involved, showing that if you want to create an unmanageable mess it's better
to bloat it up slowly over time so no-one will notice than to try and do it
all at once.

The approach to auth problems is the same as IPsec, you keep turning off as
much stuff off as you possibly can until you get to a minimal interoperable
feature set, usually barely safe if not explicitly unsafe, or you keep
tweaking parameters on both sides until you can connect without either your
patience or the customer's willingness to keep paying running out.  To see
this in action, take some common RADIUS/EAP/PEAP/whatever auth failure
message, plug it into Google, and see how many thousands of results you get
for people having that problem, and how many different guesses are posted for
what it takes to get client X to authenticate to server Y.

Now moving on to a later post:

>breaks that are most useful for state level actors, but still handy for
>individuals - breaks that rely on the collection of large amounts of data,
>and grinding through that data in big computers.

And this is why it might be a good idea to stick with IPsec or RADIUS with the
accompanying entire OSI-style Christmas tree on top, the protocols are so
difficult to get working even with legitimate access that a nation-state actor
that thinks it's recovered some keys or credentials has no way of verifying
this because they don't know whether it's the keys or the 8,000 parameters and
configuration options that you need to get exactly matched up that are
preventing it from working.  In effect each IPsec or RADIUS et al setup is a
gigantic CAPTCHA-protected system that requires hours or days of expert human
manipulation before your keys/credentials will work.

Peter.



More information about the cryptography mailing list