git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Marco Costalba" <mcostalba@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: "Andy Parkins" <andyparkins@gmail.com>, git@vger.kernel.org
Subject: Re: Why SHA are 20 bytes? (aka looking for flames)
Date: Sat, 21 Apr 2007 19:43:27 +0200	[thread overview]
Message-ID: <e5bfff550704211043s40d33187jc334c1d85330132a@mail.gmail.com> (raw)

On 4/21/07, Karl Hasselström <kha@treskal.com> wrote:
>
> Well, any hash is "incomplete" or "not long enough" inasmuch as it's
> theoretically possible to find collisions. The choice of the full 160
> bits (note: this is 20 bytes, not 40) is arbitrary -- it's just "long
> enough". 128 bits would have been enough to prevent any naturally
> occurring collisions, too (maybe even 96 bits would be enough, I'm too
> lazy to do the math). The only reason to go as high as 160 is to
> prevent any possible collision created by a malicious adversary, too,
> so that it's possible to e.g. sign just a commit and be able to trust
> everything it points to. The SHA1 designers felt that 160 bits was a
> good compromise between size and robustness, and we just trust that
> their (and the cryptographic community's) guess is good enough.
>

I think it is sensible to differentiate between

- creation of a 160bits possible unique signature

- use of whole 160bits signature to reference the object

I'm wondering that as long as we are able to calculate on the fly the
whole 160 bits signature from the object when needed then the second
point _could_ be relaxed and we could use a truncated sha (note that
is not a new sha calculated with less bits, it is the good old 160bits
sha just trucated to be used as object reference).

This could be convenient as long as collision is very unlikely, so to
work almost always with abbrev forms and fallback on full 160bits on
those rare cases.

  Marco

                 reply	other threads:[~2007-04-21 17:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=e5bfff550704211043s40d33187jc334c1d85330132a@mail.gmail.com \
    --to=mcostalba@gmail.com \
    --cc=andyparkins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kha@treskal.com \
    /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).