[Cryptography] WireGuard

[Ray Dillinger]

On 09/01/2018 10:40 AM, John-Mark Gurney wrote:
> Howard Chu wrote this message on Thu, Aug 30, 2018 at 16:56 +0100:

>> Why is that clever? Crypto algorithms have relatively short lifespans. Without startup negotiation,
>> whatever version of Wireguard you deploy today will have to be completely thrown away within a few
>> years. How are you going to coordinate the deathmarch upgrades then?
> 
> AES has been going strong for almost 20 years now, and if you use
> 256-bit, it's probably good for another few yeas...


While there are some ciphers that had good security reasons for expiring
(Remember BassOmatic and its tremendous variety of classes of weak keys?
DES and its laughable key length?)  I don't recall very many outright
sudden failures where people woke up one day and discovered that a
cipher everybody'd believed secure in the previous week could now be
broken in realtime.

A more typical scenario, as far as we've learned, is that people can see
cipher failures coming, years away.  An attack that reduces work by a
percent or two is found; eight months or so later someone figures out
how to extend it resulting in a 50% work reduction; a year after that
people take note and downrate the cipher from 256-bit to 250-bit
effective security (even though the work factor with currently known
attacks is still 255 bits) and some alarmists say "It's likely to be
broken fairly soon, we should stop using it."  Then a year and a half
after that, someone finds a way to extend the attack recursively, but
each recursion increases the computer power burden by a factor of ten.
With the breakeven point on this new attack, the work factor comes down
to about 253-bit security.

About that time, the alarmists' opinion goes mainstream and folks start
phasing that cipher out ... but this is YEARS after the original attack
was found, and nobody can yet actually read any messages encrypted in it
without converting an entire star into energy and using it all to power
nanoscale computronium that nobody can build yet. And that cipher falls
out of use and is considered broken, and gets replaced by something else.

Meanwhile, all those developers who have multiple ciphers supported, are
in their software up to their elbows, tinkering with key management,
tinkering with protocols, tinkering with algorithm negotiation, and
every line they write is an opportunity to make a catastrophic mistake.

Crippling vulnerabilities in protocols, algorithm negotiation, and key
handling, are routinely discovered between Friday Night and Monday
Morning leaving entire vast tracts of communications infrastructure
insecure with no warning whatsoever, with an implementation in the hands
of Black-hat attackers arriving before the following Thursday.

If I were designing something to have a five-year upgrade cycle, it
would be the right choice to have a cipher currently believed secure,
with key at least twice as long as "justified" for the task at hand
given known attacks, absolutely minimal protocol, and no algorithm
negotiation.  There's no way around key handling, but using a single
algorithm and a single key length can keep it simple.  So you can at
least reduce or eliminate the biggest known design security problems.

If it should become necessary to change the algorithm, I'd expect four
or five years to get a new version out before any possibility of an
actual cipher algorithm break enabling real-world attacks.  I'd have no
such confidence about an excessively complicated protocol or negotiation
phase.

				Bear



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180903/2badb800/attachment.sig>