Cryptology Project
Notes from implementing classical and modern cryptographic primitives with attention to timing, randomness, and API shape.
The part that stuck
The math matters, but the implementation boundaries matter just as much. A correct primitive can still become a bad system if it exposes sharp edges: reused nonces, weak randomness, variable-time comparisons, or APIs that make insecure defaults easy.
Project shape
Classical ciphers
Implement substitution and transposition systems to make frequency analysis concrete.
Modern primitives
Build small, testable implementations around block modes, hashing, and message authentication.
Attack harnesses
Write scripts that break deliberately weak configurations instead of only testing happy paths.
API review
Check whether the interface nudges a caller toward correct nonce handling and constant-time checks.
The main takeaway is that cryptographic code has to be boring at the boundary. The system should make the safe operation obvious and the unsafe operation hard to reach.