- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 28 Jan 2023 14:02:21 -0500
- 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 dangers. 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: https://www.youtube.com/watch?v=eYztYCbV_8U 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) https://www.digitalbazaar.com/
Received on Saturday, 28 January 2023 20:02:29 UTC