W3C home > Mailing lists > Public > public-credentials@w3.org > January 2023

Excessive Optionality in Cryptography Anti-Pattern (was: Re: JSONWebSignature2020 vs JcsEd25519Signature2022)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 28 Jan 2023 14:02:21 -0500
Message-ID: <CAMBN2CTk+yYR0OOTHtzryyHbnB4n8hy+CieVfHyUNti+fqT0-w@mail.gmail.com>
To: Tomislav Markovski <tomislav@trinsic.id>
Cc: Markus Sabadello <markus@danubetech.com>, Orie Steele <orie@transmute.industries>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>, public-vc-wg@w3c.org, silverpill@firemail.cc
On Fri, Jan 27, 2023 at 4:24 PM Tomislav Markovski <tomislav@trinsic.id> wrote:
> Side comment: I always wondered why data integrity signatures suites define the canonicalization algorithm in the suite as a constant, instead as a proof parameter using the "canonicalizationAlgorithm" term defined in the security vocab v1.

Providing optionality in cryptography libraries leads to code that's
more complex than necessary, very difficult (to impossible) to audit,
and creates foot guns for developers (who have proven to repeatedly
pick the wrong parameters in critical situations).

The ideal number of cryptographic suites for your application is two,
with zero optionality. One cryptosuite to use today, and one
cryptosuite to use when your current cryptographic system is broken.
This is quite different from the old-and-busted philosophy used in the
2000s, some of which bled into the 2010s. Thankfully, more people are
speaking out against excessive optionality in cryptographic systems
today and doing something about it (the Data Integrity work  coupled
with no option cryptosuites being one such group... Wireguard in the
Linux kernel being another).

You can see this updated approach playing out in critical software
systems today. For example, Wireguard in the Linux kernel has zero
agility and zero optionality and has been praised by Linus Torvalds as
better than the current cryptographic system in the Linux kernel.
Unsurprisingly some of the previous cryptography subsystem
implementers in the Linux kernel are taking it as an insult that their
code is being called "unsafe" and "overly complex", which completely
misses the point. Optionality leads to misuse as CVEs have
demonstrated over the years. Give developers a bad option in the name
of backward compatibility and they will use it without knowing the

There is an excellent presentation by the core kernel maintainer for
Wireguard that outlines why excessive optionality is being stripped
from systems like the Linux kernel here:


Key points above are made about auditability, reducing optionality,
and reducing agility around minute 3 and 16, though the entire
presentation (from 2016) is well worth the time.

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
Received on Saturday, 28 January 2023 20:02:29 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 20:02:31 UTC