Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?

[Fedor Brunner <fedor.brunner@azet.sk>]

On 22.11.2014 00:01, Patrick Schleizer wrote:
> Dear git developers!
> 
> Jeff King wrote:
>> On Sun, Nov 16, 2014 at 03:31:10PM +0000, Patrick Schleizer wrote:
>>
>>> How safe are signed git tags? Especially because git uses SHA-1. There
>>> is contradictory information around.
>>>
>>> So if one verifies a git tag (`git tag -v tagname`), then `checksout`s
>>> the tag, and checks that `git status` reports no untracked/modified
>>> files, without further manually auditing the code, how secure is this
>>> actually? Is it only as safe as SHA-1?
>>
>> Yes, it is only as "safe as SHA-1" in the sense that you have GPG-signed
>> only a SHA-1 hash. If somebody can find a collision with a hash you have
>> signed, they can substitute the colliding data for the data you signed.
>>
>> Of course, "safe as SHA-1" and "find a collision" are vague. If
>> pre-image attacks are feasible (i.e., given already-published SHA-1, I
>> can find a different input with the same SHA-1), then attacks are
>> trivial. But when people talk about attacks on SHA-1, they are usually
>> referring to finding a collision between two new pieces of data. You can
>> also use that in an attack, but it's much less straightforward
>> (basically, you need to get somebody to sign one of the colliding pieces
>> of data and then replace it with the other).
> 
> Sounds pretty sad. Isn't this a security issue that should be fixed?
> 
> Rather than discussing how feasible collisions in SHA-1 are... Attacks
> on SHA-1 are only getting worse, no? Since the Snowden revelations we
> know that powerful adversaries that are working on such things and would
> use such weaknesses to exploit users.
> 
> Dear git developers, could you please make a long story short? Change to
> some stronger hash algorithm? (sha256, sha512, or so?) Or provide an
> option for that?
> 
>> And of course there is the question of getting the colliding data to the
>> victim. Git does collision checks whenever a remote (e.g., from a "git
>> fetch") gives us data that we already have. So you could poison new
>> cloners with bad data, but you could not convince a repository with the
>> existing "good" half of the collision to fetch the "evil" half.
> 
> Poison git cloners with bad data is exactly my point here. Because
> sometimes I am a cloner of my own code - cloning it on a separate
> machine - then verify it using gpg - but don't check it any further. In
> such cases, I'd prefer if security wouldn't depend on SHA-1.
> 
> Cheers,
> Patrick
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Dear git developers,
how about skipping SHA-2 and moving to SHA-3 finalist BLAKE.

NIST, in the final report of the SHA-3 competition, said this about the
finalists (which included BLAKE, Keccak, Skein, and Grøstl):

    BLAKE had a security margin — the gap between a known-weak reduced
version and the full version — comparable to Keccak and superior to the
other finalists. (§4.3: “BLAKE and Keccak have very large security
margins.”)
    BLAKE had a depth of analysis — the amount of published research
analyzing its security — comparable to Grøstl and Skein and superior to
the other finalists. (§3.1: “Keccak received a significant amount of
cryptanalysis, although not quite the depth of analysis applied to
BLAKE, Grøstl, or Skein”)
    BLAKE had performance (in software) comparable to Skein and superior
to the other finalists. (§5.1.4: “Skein and BLAKE […] have the best
overall software performance.”)

http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf



Measurements of SHA-3 finalists, indexed by machine

http://bench.cr.yp.to/results-sha3.html


Fedor