Task 1: Comparison of methods for message authentication

1.1 Overview

In this task, we compare different methods used for message authentication and
integrity. These include:
Hash Functions (SHA-256)
RSA + SHA1
Digital Signatures
HMAC-SHA256

Each of these methods has specific use cases and provides different levels of
security guarantees such as integrity, authentication, and non-repudiation.

1.2 Method Comparisons

1. Hash Functions (e.g., SHA-256)

What is it used for?
Hash functions are used to generate a fixed-size output (hash value) from an input
message. This output is unique to the input, and even a small change in the input
will produce a drastically different hash.
Under what assumptions does it work?
Assumes that the hash function is cryptographically secure, meaning it should be
computationally infeasible to find two different inputs that produce the same hash
(collision resistance).
How are integrity, authentication, and non-repudiation verified?
Integrity: The recipient can compare the hash of the received message with the
provided hash. If they match, the message is considered unchanged.
Authentication: Hash functions alone don’t authenticate the sender. To achieve
authentication, the sender would need to securely share the hash value, such as by
using encryption or a digital signature.
Non-repudiation: Not achieved with hash functions alone.
Advantages and Disadvantages
Advantages: Fast and efficient for verifying message integrity.
Disadvantages: No authentication or non-repudiation, as hash functions do not
involve any cryptographic keys.

2. RSA + SHA-1
What is it used for?
RSA combined with SHA-1 is used to authenticate the message by hashing the message
and then encrypting the hash with the sender’s private key. This provides both
integrity and authentication.
Under what assumptions does it work?
Assumes the use of a secure RSA implementation with sufficiently large key sizes
(2048 bits or higher is recommended), and SHA-1 is considered secure enough for
these purposes, though it's now deprecated in favor of more secure hash algorithms
like SHA-256.
How are integrity, authentication, and non-repudiation verified?
Integrity: The recipient can recalculate the SHA-1 hash of the received message and
decrypt the sender’s encrypted hash using the sender’s public key. If the values
match, the message is intact.
Authentication: The sender’s identity is authenticated by verifying the signature
with the sender’s public key.
Non-repudiation: Since the message hash is signed with the sender’s private key,
the sender cannot deny sending the message.
Advantages and Disadvantages
Advantages: Provides both authentication and non-repudiation. The recipient can
verify the sender’s identity using the public key.
Disadvantages: RSA encryption is slower than symmetric encryption methods, and SHA-
1 is no longer considered secure. It is also computationally intensive.

3. Digital Signature
What is it used for?
A digital signature is used to prove the authenticity of a message and ensure that
it has not been altered. It involves hashing the message and encrypting the hash
with the sender’s private key.
Under what assumptions does it work?
Assumes that the sender has a private key, and the receiver can access the sender’s
public key. It relies on the assumption that the private key is kept secure and
that the public key can be trusted.
How are integrity, authentication, and non-repudiation verified?
Integrity: The recipient hashes the received message and compares it to the
decrypted hash from the signature. If they match, the message is intact.
Authentication: The sender’s identity is authenticated using the sender’s public
key.
Non-repudiation: The sender cannot deny sending the message since the message was
signed with their private key.
Advantages and Disadvantages
Advantages: Provides integrity, authentication, and non-repudiation. Strong
security with appropriate key sizes.
Disadvantages: Computationally expensive, especially with RSA, and requires careful
key management.

4. HMAC-SHA256
What is it used for?
HMAC (Hashed Message Authentication Code) with SHA-256 is a method for ensuring
both the integrity and authenticity of a message using a secret shared key and a
hash function.
Under what assumptions does it work?
Assumes that the sender and receiver share a secret key beforehand. The secret key
must remain private between the parties.
How are integrity, authentication, and non-repudiation verified?
Integrity: The recipient recalculates the HMAC of the received message using the
shared key and compares it to the HMAC received with the message. If they match,
the message is intact.
Authentication: The authenticity of the message is verified by the use of the
shared secret key. Only someone who knows the secret key can generate a valid HMAC.
Non-repudiation: HMAC does not provide non-repudiation, as both parties share the
same key, meaning either party could generate a valid HMAC.
Advantages and Disadvantages
Advantages: Efficient, fast, and uses a shared secret key, which is practical in
many scenarios. Provides integrity and authentication.
Disadvantages: Does not provide non-repudiation, as both parties know the secret
key. If the key is compromised, the entire system’s security is at risk.

Summary Table
Method Uses Assumptions Integrity Authentication Non-repudiation
Advantages Disadvantages
Hash Functions (SHA-256) Message integrity verification Cryptographically
secure hash function Yes No No "Fast, efficient" No authentication or
non-repudiation
RSA + SHA-1 Message authentication and integrity Secure RSA and SHA-1 Yes
Yes Yes Provides authentication and non-repudiation "Slower, SHA-1
deprecated"
Digital Signature Proving message authenticity Secure private/public key pairs
Yes Yes Yes Provides strong security Computationally expensive
HMAC-SHA256 Message integrity and authentication Shared secret key Yes Yes
 No "Fast, practical for many use cases" "No non-repudiation, shared
key risk"

Each method has its strengths and trade-offs. Hash functions like SHA-256 are quick
but lack authentication and non-repudiation. RSA and digital signatures provide
strong security and authentication but are slower. HMAC is efficient and suitable
for scenarios where a shared secret key exists but does not provide non-
repudiation.

Task 2: MD5 collision

2.1 Overview

In this task, we aim to demonstrate and explore the concept of MD5 collisions,
which involves generating two distinct files that produce the same MD5 hash value.
This phenomenon occurs due to weaknesses in the MD5 algorithm, which allows
attackers to create different files that are indistinguishable based on their hash
values.
To achieve this, we will use the md5collgen tool, which generates these collisions
by manipulating the content of the files while maintaining the same hash. This task
provides an opportunity to study the practical implications of cryptographic
vulnerabilities and understand the importance of choosing secure hash algorithms
for applications like digital signatures and file integrity verification.
Key Points:
Generate MD5 Collision: Using md5collgen to create two different files with the
same MD5 hash.
Tools Used: md5collgen, md5sum, and a hex editor for file inspection.
Exploring MD5 Vulnerabilities: Understanding how MD5 collisions occur and why MD5
is no longer recommended for security-sensitive applications.
By the end of this task, we will have demonstrated the process of creating MD5
collisions and observed how the tool manipulates file contents to produce identical
hashes.

2.2 Experiment Summary

Objective: The goal of the experiment is to generate two distinct files that have
the same MD5 hash. This is done using the md5collgen program, which allows us to
generate two different files with the same MD5 hash by providing a prefix file.
Steps:
Generate Prefix File: The first step is to create a prefix file. This file can
contain any arbitrary content. For example, it could be a simple text file or
binary data.

Run the md5collgen Program: The md5collgentool is then run with the prefix file as
input. The following command was used:

md5collgen -p prefix.txt -o out1.bin out2.bin

This command generates two binary files (out1.bin and out2.bin), each with the same
MD5 hash but different content beyond the prefix.

Verification:
Check if Files are Different: We can use the diff command to compare the two output
files (out1.bin and out2.bin). Since they are supposed to be different files, the
diff command should show differences:
diff out1.bin out2.bin
Check MD5 Hash: We use the md5sum command to check the MD5 hash of both files:
md5sum out1.bin
md5sum out2.bin
Both files should produce the same MD5 hash, despite being different files.

Hex Editor: To visually inspect the files, we used a hex editor (e.g., bless) to
view out1.bin and out2.bin in binary form. This helps us observe where the files
differ and how the MD5 collision was achieved.

Answers to Questions in Task 1:

Question 1: If the length of your prefix file is not a multiple of 64, what is
going to happen?
Answer: If the length of the prefix file is not a multiple of 64 bytes, padding
will be added to the prefix file to make its length a multiple of 64. This is
because MD5 processes data in blocks of 64 bytes. If the file length is not a
multiple of 64, the tool will add necessary padding (usually with zeros) to make it
align correctly with MD5's block size.
Question 2: Create a prefix file with exactly 64 bytes, and run the collision tool
again. What happens?
Answer: When the prefix file is exactly 64 bytes, it is already the correct length
to be processed by MD5 without requiring any padding. Running the md5collgen tool
with a 64-byte prefix results in two different output files that still have the
same MD5 hash, but in this case, the collision will happen at the next level of the
MD5 hash computation. The collision mechanism works by adjusting the padding and
modifying certain bits in the file such that the final hash is the same.
Question 3: Are the data (128 bytes) generated by md5collgen completely different
for the two output files? Please identify all the bytes that are different.
Answer: Yes, the data generated by md5collgen for the two output files are
different, but the MD5 hash of both files is the same. Specifically, the first part
of both files (the prefix) will be identical. However, the second part (the padding
and modifications made by the tool to create the collision) will differ. The bytes
that differ are generally in the padding area, and it is typically the final 64
bytes (or more) that are altered between the two files to achieve the MD5
collision. Using a hex editor, one can pinpoint the exact byte positions where the
differences occur. These differences are structured in a way that does not affect
the final MD5 hash but ensures that the files are distinct.

In summary:
Prefix: Identical in both files.
Modified Section: Different between the two files but designed to create the same
MD5 hash.