Assignment Overview
This solved assignment covers two different cybersecurity tasks. Question 2 explains the Double Ratchet Algorithm and its security properties. Question 3 uses GPG to determine which supplied product file is authentic and then explains why signature validity and public-key trust are separate decisions.
Requirement → Solution Map
Step-by-Step Solved Assignment
Explain the Double Ratchet Architecture
Explain the architecture and design of the Double Ratchet Algorithm, including the Diffie Hellman ratchet, symmetric key ratchet and message flow.
The Double Ratchet Algorithm is what apps like Signal, WhatsApp, and Facebook Messenger use for end to end encryption. The main idea is simple: every single message gets its own unique key. It does this by combining two ratchets.
The solution separates the design into the Diffie Hellman ratchet and the symmetric key ratchet, then shows the Alice-to-Bob message flow and a complete text diagram.
This makes it clear how root keys, chain keys and one-time message keys work together instead of treating the algorithm as a single black box.
1. Diffie Hellman (DH) Ratchet
This runs whenever you receive a new DH public key from the other person. It does a DH exchange between your current private key and their new public key. The result goes into a KDF which makes a new Root Key (RK) and Chain Key (CK). You also make a fresh DH key pair for your next sending chain.
2. Symmetric Key Ratchet
This runs for every message inside a chain. It takes the current Chain Key and uses a KDF to create a Message Key (MK) plus the next Chain Key. The Message Key encrypts or decrypts just one message, then gets deleted right away.
How messages flow (Alice → Bob)
Alice uses her sending chain key to make a message key, encrypts her plaintext, and sends the ciphertext with her current DH public key. Bob receives it, does a DH ratchet step with his private key and Alice's public key to get the same root key and a new receiving chain key, then uses his symmetric ratchet to derive the message key and decrypt.
View the Double Ratchet diagram
ALICE BOB
+----------+ +----------+
| RK, CKs | | RK, CKr |
| DHs | | DHr |
+----------+ +----------+
| |
| 1. DH Ratchet: | 1. DH Ratchet:
| RK, CKr = KDF(RK, DH(DHs,DHr)) | RK, CKs = KDF(RK, DH(DHr,DHs))
| |
| 2. Symmetric Ratchet (send): | 2. Symmetric Ratchet (receive):
| MK, CKs = KDF(CKs) | MK, CKr = KDF(CKr)
| |
| 3. C = ENC(MK, Plaintext) | 3. Plaintext = DEC(MK, C)
| |
| 4. Send (DHs, C) --------------> | 4. Receive (DHs, C)
| |
v v
[delete MK, old CKs] [delete MK, old CKr]Explain the Security Properties
Explain how the design provides Forward Secrecy and Post Compromise Security.
This means if an attacker steals your current keys, they still cannot read old messages. The symmetric ratchet gives this because each message key is derived and then deleted immediately. Since the KDF is one way, you cannot reverse it. Old DH private keys are also deleted. So even if a device is compromised today, old conversations remain safe. This is the self healing property. If an attacker compromises the current state, the session recovers once a new DH exchange happens. When one party sends a message with a new DH public key, a fresh DH secret is computed. The attacker does not have the new private keys, so they cannot compute this secret. All future messages become secure again. This is the major advantage over just using a symmetric ratchet alone.
The solution connects deletion of old message keys to Forward Secrecy and a fresh Diffie Hellman exchange to recovery after compromise.
The answer does more than name the properties. It explains which ratchet behaviour creates each security property.
This means if an attacker steals your current keys, they still cannot read old messages. The symmetric ratchet gives this because each message key is derived and then deleted immediately. Since the KDF is one way, you cannot reverse it. Old DH private keys are also deleted. So even if a device is compromised today, old conversations remain safe.
This is the self healing property. If an attacker compromises the current state, the session recovers once a new DH exchange happens. When one party sends a message with a new DH public key, a fresh DH secret is computed. The attacker does not have the new private keys, so they cannot compute this secret. All future messages become secure again. This is the major advantage over just using a symmetric ratchet alone.
Verify the Product Files with GPG
Use the supplier public key and detached signature to determine which of the three product files is authentic.
I need to find out which of the three product files is the real one from the supplier. The supplier gave us a signature file (product.txt.sig) and their public key (supplier_public_key.asc). I used GPG on the command line to check each file.
The public key is imported, each file is checked against the same detached signature, and only product_3.txt produces a valid signature.
The verification result proves which file matches the exact content that was signed with the corresponding private key.
Product Files
View the three supplied product files
PRODUCT INFORMATION
Product ID: ACS-1047
Product Name: Security Scanner 1.2.335
Category: Computer Security
Supplier: ACS (11907 and 11940) Pty Ltd
Status: Active
Additional: kzvPM0kcBCRWsBKCah2Li+V9W/hG4QsFz3wMlkkdLbYq/1+ooq3A9TCWTgUNzU/jrxmnb3INwMvsYpV2rg4w2wPRODUCT INFORMATION
Product ID: ACS-1047
Product Name: Security Scanner 1.2.335
Category: Computer Security
Supplier: ACS (11907 and 11940) Pty Ltd
Status: Active
Additional: kzvPM0kcBCRWsBKCah2Li-V9W/hG4QsFz3wMlkkdLbYq/1+ooq3A9TCWTgUNzU/jrxmnb3INwMvsYpV2rg4w2wPRODUCT INFORMATION
Product ID: ACS-1047
Product Name: Security Scanner 1.5.335
Category: Computer Security
Supplier: ACS (11907 and 11940) Pty Ltd
Status: Active
Additional: kzvPM0kcBCRWsBKCah2Li-V9W/hG4QsFt3wMlkkdLbYq/1+ooq3A9TCWTgUNzU/jrxmnb3INwMvsYpV2rg4w2wGPG Verification
Step 1: Import the Supplier's Public Key
First I imported the public key into my GPG keyring:
gpg --import supplier_public_key.ascI confirmed the key was imported:
gpg --list-keysStep 2: Verify product_1.txt
gpg --verify product.txt.sig product_1.txtResult: INVALID
Step 3: Verify product_2.txt
gpg --verify product.txt.sig product_2.txtResult: INVALID
Step 4: Verify product_3.txt
gpg --verify product.txt.sig product_3.txtResult: VALID
gpg: Signature made Sat 05 Sep 2026 08:56:19 AM PKT
gpg: using RSA key A3B6F51E2371E88D9D943C92443546227039069C
gpg: Good signature from "ACS (11907 and 11940) Pty Ltd" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: A3B6 F51E 2371 E88D 9D94 3C92 4435 4622 7039 069CVerification Summary
| File | Product Name | Status |
|---|---|---|
| product_1.txt | Security Scanner 1.2.335 | INVALID |
| product_2.txt | Security Scanner 1.2.335 | INVALID |
| product_3.txt | Security Scanner 1.5.335 | VALID |
- product_3.txt is the real one. The signature matches perfectly, so nobody changed the file after the supplier signed it. It correctly shows "Security Scanner 1.5.335" and the Additional field has Ft3wMlkkdLbYq.
- product_1.txt has an older product name. It says "Security Scanner 1.2.335" instead of "1.5.335" and the Additional field has Fz3wMlkkdLbYq instead of Ft3wMlkkdLbYq. The signature fails, which means the file was modified after signing. It is not authentic.
- product_2.txt looks similar to product_1.txt. It also shows "Security Scanner 1.2.335" with the Additional field Fz3wMlkkdLbYq. The signature fails here too. Even though it may look like a valid product file, the hash is different from the signed original, so GPG reports a BAD signature. It is not authentic.
Separate Signature Validity from Key Trust
Explain the difference between a mathematically valid digital signature and trust in the identity behind the public key.
These two sound similar but they are actually totally different.
Validity = "The math works". Trust = "I believe this key is really from who it says".
A valid signature can prove that a file matches a key, while key trust asks whether that key really belongs to the claimed supplier.
- This is just math. It asks: "Does this signature match this file using this public key?"
- If yes, the file has not been changed since signing, and the signature was made with the matching private key.
- A "Good signature" just means the cryptography checks out. That is it.
- In our case, product_3.txt had a good signature. product_1 and product_2 did not.
- This is about identity. It asks: "Is this public key really owned by who it claims to be?"
- Just because a signature is valid does not mean the key actually belongs to the supplier. Anyone could make a key pair, sign a file, and pretend to be "ACS Pty Ltd".
- Trust is built by:
- Checking the fingerprint through a separate channel (like calling them)
- Having others you trust sign the key (web of trust)
- Using a certificate authority
- During verification, GPG warned us: "This key is not certified with a trusted signature!". This means the key works, but we have not confirmed it is really ACS.
Trust = "I believe this key is really from who it says"
So you could have a file with a valid signature but from an untrusted key. In that case, you should verify the key's fingerprint through another trusted method before trusting the file. In our assignment, product_3.txt is valid, but we would still want to confirm the key's fingerprint with the supplier directly to be completely certain.
Need help with a similar assignment or project?
Send your assignment brief, marking rubric or existing work for originality-focused support, technical review, troubleshooting and project guidance tailored to your requirements.
What Students Should Learn From This Assignment
The Double Ratchet should be explained as two linked key-evolution processes, not only as a definition.
Forward Secrecy protects earlier messages, while Post Compromise Security explains how future messages can become secure again after fresh Diffie Hellman material is introduced.
Digital signatures should be verified against the exact file content. A small content change is enough to invalidate the signature.
A valid signature proves that the mathematics checks out for a key, but it does not by itself prove that the key belongs to the claimed organisation.
Good technical answers connect command output or diagrams to an explanation of what the evidence proves.