Implement a Cipher From Mathematical Specification and Analyse a Real Vulnerability

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

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.

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

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.

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

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.