git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Personal Sam Smith <sam@samuelsmith.org>, dwh@linuxprogrammer.org
Cc: git@vger.kernel.org
Subject: Re: Preserving the ability to have both SHA1 and SHA256 signatures
Date: Sun, 16 May 2021 22:23:56 -0500	[thread overview]
Message-ID: <60a1e1cc5b8b6_11206d20830@natae.notmuch> (raw)
In-Reply-To: <D433038A-2643-4F63-8677-CA8AB6904AE1@samuelsmith.org>

Personal Sam Smith wrote:
> One of the essential properties of any good cryptographic system is
> what is called cryptographic algorithm agility. Without it the system
> cannot easily adapt to new attacks and newly discovered weaknesses in
> cryptographic algorithms. Self-describing cryptographic primitives are
> the most convenient enabler for cryptographic agility. One advantage
> of signed hash chained provenance logs is that the whole log must be
> compromised not merely one part of it. Such a log that exhibits
> agility especially through self-describing primitives is self-healing
> in sense that new appendages to the log may use stronger crypto
> primitives which protect earlier entries in the log that use weaker
> primitives. This makes the log (or any such agile self-describing
> verifiable data structure) future proof. It is the best practice for
> designing distributed (over the internet) zero trust computing
> applications. 

This is way above my pay grade, but let me try to interpret the above.

If we have a repository with two digest algorithms:

 2. BLAKE2b (considered non-compromised)
 1. SHA-1 (broken)

We may not be confident on the SHA-1 history (1), but as long as we have
BLAKE2b history (2), we can be confident on that.

The delta between when SHA-1 was broken, and the switch to BLAKE2b
happened, is when the repository could be potentially compromised.

So, it's in the best interest of the repository owners to switch to the
non-compromised version as soon as possible. In fact, it would be better
if the switch happened *BEFORE* SHA-1 was broken.

This is why algorithm agility is important.


But this is not sufficient, because BLAKE2b could get
compromised in the future. The repository owners need to be thinking
ahead to the time, to when they'll need to make yet another algorithm
switch.

When such times comes, they need their infrastructure to be able to
perform the switch as fast as possible. If possible right after they've
finalized their decision.


So, if I can summarize your and dwh's proposal: git should be
cryptographic-digest-algorithm-agnostic.


So far this makes sense to me.

The only problem comes when you consider day-to-day operations, which to
be honest have been totally uninterrupted by 15 years of using SHA-1.

At this point it's worth noting that if the git project has a maxim, it
would be a single word: "performance". Nothing else matters.

So, if you suggest to switch from SHA-1 to SHA-256, that's fine; as long
as you can guarantee that *performance* is not affected. This is the
work brian m. carlson seems to have been doing.

On the other hand what dwh seemed to suggest is to support every digest
algorithm on the horizon--without regards of how that would affect
performance--and as expected that didn't land very smoothly.


But I don't think the two approaches are incompatible.

All we have to do is reconcile two facts:

  1. The ability for users to switch to a new digest is important
  2. We don't want users to be switching algorithms every other commit

If git can switch the digest algorithm on a per-repository basis, I
don't think anybody would have a problem with that.

Git could support SHA-1, SHA-256, and BLAKE2b as of today. The
repository owners can decide wich algorithm to choose today, and their
past history would not be affected.

This is future-proof, and would make repository owners be able to make
that decision, not git.

If at some point in the future people want to start to get ready for
SHA-4, that could be introduced to the git core, *before* people want to
make such transition, and *after* the project has made sure such change
does not impact on performance.

Or am I missing something?

Cheers.

-- 
Felipe Contreras

  reply	other threads:[~2021-05-17  3:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 20:57 Preserving the ability to have both SHA1 and SHA256 signatures Personal Sam Smith
2021-05-17  3:23 ` Felipe Contreras [this message]
2021-05-17  6:49   ` Cryptographic hash agnostic git (was: Re: Preserving the ability to have both SHA1 and SHA256 signatures) Bagas Sanjaya
  -- strict thread matches above, loose matches on Subject: below --
2021-05-08  2:22 Preserving the ability to have both SHA1 and SHA256 signatures dwh
2021-05-08  6:39 ` Christian Couder
2021-05-08  6:56   ` Junio C Hamano
2021-05-08  8:03     ` Felipe Contreras
2021-05-08 10:11       ` Stefan Moch
2021-05-08 11:12         ` Junio C Hamano
2021-05-09  0:19 ` brian m. carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60a1e1cc5b8b6_11206d20830@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=dwh@linuxprogrammer.org \
    --cc=git@vger.kernel.org \
    --cc=sam@samuelsmith.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).