SHA-1 vs SHA-256 in Git

1. Introduction to Hash Functions in Git

Git's integrity model relies on cryptographic hash functions to uniquely identify and verify all content stored in a repository. Each commit, tree, blob (file content), and tag is identified by the hash of its contents, creating a content-addressable storage system.

When Git computes a hash:

• It first prepends a header identifying the object type and size
• Then it computes the hash of this prepared content
• The resulting hash becomes the object's identifier in the Git database

This approach ensures that any change to content, however small, produces a completely different hash.

2. SHA-1 Algorithm Explained

2.1 SHA-1 Basics

SHA-1 (Secure Hash Algorithm 1) is a cryptographic hash function that produces a 160-bit (20-byte) hash value, typically rendered as a 40-character hexadecimal string. Developed by the NSA and published in 1995, it became a widely-used standard for digital security.

The algorithm processes messages in 512-bit blocks and maintains a 160-bit internal state divided into five 32-bit words. The core operations include:

1. Message padding and length encoding
2. Message block processing with bitwise operations (AND, OR, XOR, NOT)
3. Rotation and addition operations that mix the data
4. Compression function that updates the state for each block
5. Final output generation from the internal state

2.2 How Git Uses SHA-1

In Git's implementation:

object_hash = SHA1("blob " + content_size + "\0" + file_content)

For example, when Git hashes a file:

1. It prepends "blob 12345\0" (where 12345 is the content size in bytes)
2. This ensures different object types with identical content have different hashes
3. The resulting hash becomes the object's filename in .git/objects/

Git stores objects in a path derived from their hash:

• The first 2 characters form the directory name
• The remaining 38 characters form the filename
• Example: a hash of a1b2c3d4e5... is stored at .git/objects/a1/b2c3d4e5...

3. Security Implications of SHA-1

3.1 Collision Vulnerabilities

A hash collision occurs when two different inputs produce the same hash output. For secure systems, collisions should be computationally infeasible to generate deliberately.

SHA-1's security weakened over time:

• 2005: Theoretical attacks suggested SHA-1 would be vulnerable
• 2017: The "SHAttered" attack demonstrated the first practical collision
• 2020: The "SHA-1 is a Shambles" attack further reduced the cost of creating collisions

3.2 Impact on Git

Git's vulnerability to SHA-1 collisions is nuanced:

1. High Barrier to Exploitation: Generating malicious collisions that comprise valid Git objects remains difficult
2. Content Verification: Git's object model includes size and type metadata, which adds protection
3. Signed Commits: Repositories using signed commits have additional verification layers

However, as a system designed for long-term storage of valuable code, Git's reliance on a compromised hash function is problematic for long-term security guarantees.

4. SHA-256 as the Solution

4.1 SHA-256 Characteristics

SHA-256 belongs to the SHA-2 family and offers significant improvements:

• Produces a 256-bit (32-byte) hash value (64 hexadecimal characters)
• Uses a more complex internal structure with 8 words of state instead of 5
• Employs additional mixing functions and constants
• Has no known practical collision attacks
• Widely adopted as the current industry standard for secure hashing

4.2 Technical Implementation in Git

Transitioning to SHA-256 affects Git's internals in several ways:

1. Object Naming: Longer hash identifiers throughout the system
2. Directory Structure: Changed to accommodate longer hash names
3. Protocol Changes: Network protocols must transfer and verify larger hashes
4. Index Format: The packfile index format requires updates to store larger hashes
5. API Changes: All interfaces dealing with object identifiers need modification

6. Transition Status and Practical Advice

7. Technical Demonstration

To experiment with SHA-256 in Git (requires a compatible Git build):

# Create a repository using SHA-256
git init --object-format=sha256 test-repo
cd test-repo

# Create and commit content
echo "test" > file.txt
git add file.txt
git commit -m "Initial commit"

# Examine the resulting objects
git rev-parse HEAD
find .git/objects -type f | sort

The SHA-256 hash will be 64 characters long rather than the 40 characters of SHA-1.

8. Conclusion

The transition from SHA-1 to SHA-256 represents an important security upgrade for Git. While the transition is complex and still in progress, it ensures Git's continued reliability as a secure content-addressable storage system for the foreseeable future.

This change highlights Git's commitment to maintaining strong cryptographic guarantees while preserving compatibility with existing workflows and repositories.