| |||||||||||||
Security in the 20-teensSecurity in the 20-teensPosted Feb 1, 2010 18:28 UTC (Mon) by joey (subscriber, #328)Parent article: Security in the 20-teens
But that nice assumption only holds true for as long as one assumes that the hash algorithms used to identify commits are not subject to brute-force collisions. One should be careful about such assumptions when the computing resources of a national government can be brought to bear. We might still detect an attempt to exploit a hash collision - but our chances are not as good.Of course there is at least one VCS that does not rely on hashing for security, and instead relies on gpg signatures. The question then becomes: Is cracking a typical length gpg key within the means of a government? Hmm.. Hashing is in some ways *better*, because at least with a hash collision, some random colliding data is nearly certain to be needed. While if a gpg key is cracked, completely plausible commits could be made. I outlined some ways that sha1 collisions could be used against git repositories here. The second attack mentioned there is not very useful to a government; it's useful for project members who want to attack a project and cover their tracks. The first attack could be more useful for a government. Perhaps a second git repo is not needed; instead their great firewall could replace a file with a colliding version in passing. Also, sha1 collisions don't need a government to exploit them. They're about at the level where a university can muster the equipment to generate a collision.
(Log in to post comments)
Bwahaha... Posted Feb 2, 2010 15:50 UTC (Tue) by khim (subscriber, #9252) [Link] Of course there is at least one VCS that does not rely on hashing for security, and instead relies on gpg signatures. ...which rely on the hashing for speed: typical GPG signature signs not the message itself but the hash of the message! This makes it potentially more vulnerable not less. The rest of the message is moot point. Sure it may be good idea to use GPG signatures as defence from other attack vectors, but to say that GPG signatures can be used as defense against hash collisions... it's the height of folly.
Security in the 20-teens Posted Feb 2, 2010 22:43 UTC (Tue) by djao (subscriber, #4263) [Link] Of course there is at least one VCS that does not rely on hashing for security, and instead relies on gpg signatures. Uh, what? GPG signatures themselves rely on hash functions. From the GPG manual: A document's digital signature is the result of applying a hash function to the document.
Security in the 20-teens Posted Feb 2, 2010 23:38 UTC (Tue) by njs (guest, #40338) [Link]
Even if GPG were signing the source code itself, rather than a hash of it, it would be unusable for the DVCS case, because the important feature of DVCS chained hashing is that the hash covers *the entire history*. No-one's going to hand GPG the entire history of their project (which easily reaches the terabyte range) on every commit.
Security in the 20-teens Posted Feb 7, 2010 1:26 UTC (Sun) by vonbrand (subscriber, #4458) [Link] You are mistaken. E.g., git doesn't hash the whole repo each time I commit something, what is hashed as a commit is just the contents of a file containing pointers (as SHA-1 hashes) of its parents and any file contents referenced. You can also GPG-sign a tag for added security.
Security in the 20-teens Posted Feb 7, 2010 3:09 UTC (Sun) by njs (guest, #40338) [Link]
You misread :-). Certainly git doesn't hash the whole repo, it uses the chained hashing trick (the "pointers" you mentioned). This subthread is about what happens if you don't trust hashes -- you certainly can't use the chained hashing trick.
|
|||||||||||||