On Sat, Jan 28, 2023 at 12:04 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:
> 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).
>
Manu’s post on excessive cryptographic optionality in modern designs (a
month and a half ago now!) inspired me to write an article that I’ve been
considering for a while, on the problems of crypto agility:
https://www.blockchaincommons.com/musings/musings-agility/
In it, I outline some of the fundamental problems with crypto agility, such
as high costs, bad interactions, and downgrade attacks, and also detail
some of the alternatives, such as cipher suites, expiration dates, methods,
and good usage of layering.
I definitely agree that we need to move beyond what I feel is a dated
design principle from the 90's & '00s!
My article goes into this topic in more depth. I also have other "Musings
of a Trust Architect" articles that go into depth on progress disclosure,
data minimization & selective disclosure at:
https://www.BlockchainCommons.com/musings
I hope you find these musings useful, and I welcome comments.
-- Christopher Allen
Received on Wednesday, 8 March 2023 03:02:50 UTC