Milestone map
Milestone map
3 milestones
Implement AES and RSA From First Principles
10–18 weeks (includes mathematical prerequisites)
Study the mathematical foundations of symmetric encryption (AES, block cipher modes) and public-key cryptography (RSA). Implement AES encryption and decryption without using a cryptographic library for the core algorithm — including the key schedule, SubBytes, ShiftRows, MixColumns, and AddRoundKey steps. Separately, implement RSA from first principles: key generation from two primes, modular exponentiation, encryption, and decryption.
Proof required
Submit: a public GitHub repository containing your AES implementation (with test vectors from NIST FIPS 197) and your RSA implementation (key generation, encrypt, decrypt — with a test demonstrating round-trip correctness); and a written explanation (300 words) of why AES is considered secure and what 'semantic security' means in practical terms. A cryptographer, security researcher, or CS lecturer with cryptography experience must review the implementations and confirm they are correct.
What gets checked
- AES implementation passes NIST FIPS 197 known-answer test vectors — not just informal round-trip tests
- RSA implementation includes key generation from actual primes — not hardcoded example keys
- A cryptographer or security researcher has confirmed both implementations are correct and the security explanation is accurate
Common mistakes
- Using a cryptographic library (OpenSSL, PyCryptodome) for the core algorithm — the proof requires implementing the algorithm, not calling it
- RSA implementation that skips primality testing and uses small primes — secure RSA parameters require real key generation
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Run the AES implementation against NIST FIPS 197 known-answer test vectors — does it produce correct ciphertexts?
- Ask: 'why is ECB mode insecure for encrypting images?' — tests mode-of-operation understanding beyond AES
- Does the semantic security explanation correctly describe the property — not just 'hard to break'?
You'll sign in first, then come straight back here.
Analyse a Real TLS 1.3 Handshake and Implement HMAC
8–12 weeks (after milestone 1)
Study digital signatures (RSA-PSS, ECDSA), certificate chains, and how TLS 1.3 uses these primitives together. Implement HMAC-SHA256 without using a MAC library. Capture a real TLS 1.3 handshake in Wireshark and annotate it, identifying each message, what cryptographic operation it performs, and which key material it uses.
Proof required
Submit: a public GitHub repository containing your HMAC-SHA256 implementation with test vectors from RFC 2104; a Wireshark capture of a TLS 1.3 handshake with an annotated walkthrough (at least 400 words) identifying each message and the cryptographic operation it performs; and a brief analysis (200 words) of what properties ECDSA provides that plain RSA signing does not. A cryptographer, security practitioner, or CS lecturer must confirm the walkthrough is accurate.
What gets checked
- HMAC implementation passes RFC 2104 test vectors
- TLS 1.3 walkthrough identifies every handshake message and its cryptographic role — not just names the messages
- A cryptographer or security practitioner has confirmed the walkthrough is accurate
Common mistakes
- Wireshark walkthrough that identifies message names without explaining what each message does cryptographically
- ECDSA analysis that describes the output ('shorter signatures') without addressing the mathematical security difference from RSA
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the HMAC implementation pass RFC 2104 test vectors?
- Does the TLS walkthrough correctly identify the ClientHello, ServerHello, handshake key derivation, and Finished messages?
- Ask: 'what would happen if TLS skipped the Finished message?' — tests understanding of the Finished message's authentication role
You'll sign in first, then come straight back here.
Demonstrate and Present a Cryptographic Attack
6–10 weeks (after milestone 2)
Study a real cryptographic attack in depth — one of: padding oracle attack, BEAST, CRIME, timing side-channel on RSA, or chosen-ciphertext attack on an unauthenticated cipher. Implement a proof-of-concept of the attack on a controlled environment you own. Write a technical report (600 words) explaining the attack, why it works, and the correct defence.
Proof required
Submit: a technical report (at least 600 words) explaining the attack, its mathematical basis, and the correct defence; a public GitHub repository with a proof-of-concept on a controlled environment you own; and a recording or transcript of a presentation to a cryptographer or security practitioner who asked at least two challenging questions about the attack mechanics.
What gets checked
- Proof-of-concept demonstrates the attack on a system you control — not a theoretical description only
- Report explains the mathematical reason the attack works — not just 'it exploits a vulnerability'
- At least two specific challenging questions about attack mechanics were asked in the presentation
Common mistakes
- Report that describes the attack at a high level without explaining the cryptographic primitive failure
- Proof-of-concept that describes the attack setup but does not actually execute it against the target
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the proof-of-concept actually execute the attack on a controlled system — not just describe it?
- Does the report explain the mathematical reason for the vulnerability?
- Were at least two specific challenging questions asked about attack mechanics in the presentation?
You'll sign in first, then come straight back here.