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

Inline:

On Fri, Mar 10, 2023 at 5:32 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> Two more links on this topic, that I should add to my article:
>
>    - Ian Grigg's "The One True Cipher Suite"
>    https://iang.org/ssl/h1_the_one_true_cipher_suite.html circa ~2008:
>
> KEYQUOTE: "In cryptoplumbing, the gravest choices are apparently on the
> nature of the cipher suite. To include latest fad algo or not? Instead, I
> offer you a simple solution. Don't. *There is one cipher suite, and it is
> numbered Number 1.*"
>
>
>    - Ian Grigg's "Pareto Secure"
>    https://iang.org/papers/pareto-secure.html circa 2005
>
> KEYQUOTES: "terms Pareto-secure and Pareto-secure improvement to refer to
> security metrics resulting from allocations of competing choices in an
> overall design. A change is a Pareto-secure improvement if a measurable and
> useful improvement in security results, at no commensurate loss of security
> elsewhere."
>
> "we cannot suggest that either of TLS+TTP, or SSH+user-confirm are
> Pareto-secure. Substitution of either key exchange regime results in
> benefits but more importantly, costs."
>
>
> My frustration last month was that Wikipedia still offers no qualifiers or
> criticism of cryptographical agile architectures, but as you can see from
> Ian Grigg's quotes above, criticism goes back quite a while.
>
> My frustration this week was that someone knowledgeable and influential in
> IETF asked us to add crypto-agility to a protocol that has exactly one
> cryptographic choice — SHA256 for a hash algorithm. 🤷🏻‍♂️
>

You mean you don't want to support Md5, Blake2b, Shake, Keccak, etc... ?
Small tent vibes ; )

What happens when SHA256 gets broken like Md5?

What happens when an embedded system already supports EdDSA which requires
SHA512, and has no room for another hash function?

Here is another quote from Ian circa 2009:

There are two poles of thought.

Pole One is "agility" which involves being able to switch between
different algorithms within packets and protocols.  So if an algorithm
goes belly up, the market migrates by switching over that algorithm.

Pole Two is "the one true cipher suite."  PGP 2 and so forth.  The
notion here is that you design it well, you design it balanced, and you
plan on it lasting at least 10 years.  If not 20 or 30.  Then, you throw
the whole lot out in 10 years.

Whether you gravitate around Pole One or Pole Two depends on a whole
host of factors:  economics, business, distributions, compatibility,
structure of players, law & barriers, engineers & polemicists,
cryptoreligion, etc.

For my money, Pole Two delivers much more bang for buck.  There has
never been in modern history a complete collapse of a well-designed
suite.  But there have been huge, monstrous, embarrassing efforts spent
and lost in maintaining "agile" suites;  if the OSS's sabotage manual
were updated today, it would almost certainly include a section
suggesting much attention paid to perfect agility.

- https://mailarchive.ietf.org/arch/msg/openpgp/oo9VWaqJAfNxeOPhZjO1VFuBxB4

... "There has never been in modern history a complete collapse of a
well-designed suite."

post quantum cryptography has entered chat ...

I do love the "Pole Two: Tempt Fait" attitude though... Kinda reminds me of
burning the boats after you land for an attack, so you know there is no
going back, only victory or death.

I also love the idea of telling governments to throw crypto out every 10
years... Some of them are still on windows server 2003.

See the timeline section here:

https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

I'm a "Pole One Guy", it seems HPKE authors are as well.


> -- Christopher Allen
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>