Security
CipherWeb
Ten classical and modern ciphers, implemented from the spec.
- Year
- 2024
- Role
- Sole engineer
- Type
- Security
What it is
CipherWeb came out of my cyber security degree. It implements ten ciphers in the browser — Caesar, Vigenere, Gronsfeld, Vernam, Rail Fence, Polybius Square, Morse, Huffman, Blowfish and RSA — and lets you encrypt or decrypt text with any of them, with results stored in Firebase. Every algorithm is written from its specification rather than pulled from a library, because reading about a cipher and implementing one turn out to be very different activities.
By the numbers
- 10
- Ciphers implemented
- 0
- Crypto libraries used
- 01Plaintextuser input
- 02Select1 of 10
- 03Key scheduleper algorithm
- 04Transformencrypt / decrypt
- 05Ciphertextrendered
- 06StoreFirebase
Ten algorithms, four different ideas
The ten are not variations on one theme — they fall into distinct families, and implementing them side by side is what makes the differences legible. Caesar, Vigenere and Gronsfeld are substitution: they replace characters. Rail Fence and Polybius are transposition: they keep the characters and move them. Morse and Huffman are encodings rather than ciphers at all — Huffman is compression, and including it honestly means labelling it as such.
Then there is the jump to Blowfish and RSA. One is a symmetric block cipher with a real key schedule and Feistel rounds; the other is asymmetric and rests on modular arithmetic with large numbers. Going from a Caesar shift to RSA in one project is the clearest way I have found to feel the gap between a puzzle and actual cryptography.
Why implement rather than import
The point of the project was learning, and you cannot learn a key schedule by calling a function that has one. Writing Blowfish's subkey initialisation by hand, or getting RSA's modular exponentiation to behave, teaches you where the sharp edges are in a way that reading the Wikipedia article does not.
The interface uses Canvas to draw what transposition ciphers are doing, because Rail Fence in particular is far easier to understand as a picture of characters moving between rails than as a paragraph of prose.
The conclusion it argues for
Implementing these is exactly why I would never ship my own crypto in production. A textbook RSA implementation without proper padding is breakable, timing behaviour leaks information, and a key schedule with a subtle off-by-one still produces plausible-looking ciphertext that is simply wrong.
That is the useful outcome of the project, and the reason it belongs in this portfolio rather than in a drawer. It is where the instinct came from that shows up in everything else here — validate at the boundary, never trust the client, and be suspicious of code that looks correct because the output looks scrambled.
Decisions
Four calls I would make the same way again
01
From the specification, no crypto libraries
Importing a library would have produced a better tool and taught me nothing. The entire value of the project was in the implementations, so using someone else's would have removed the reason to build it.
02
Label Huffman honestly
Huffman coding is compression, not encryption, and it sits in the list because it is a related transformation worth understanding. Presenting it as a cipher would have been the easy and slightly dishonest choice.
03
Draw the transpositions
Rail Fence and Polybius are spatial algorithms. A Canvas rendering of characters moving between rails explains in one glance what a paragraph of description does not.
04
Educational, and labelled as such
Nothing here is safe for real secrets, and the project says so. A tool that implements textbook RSA and lets the user believe it is secure would be worse than no tool.
Stack
Substitution
- Caesar
- Vigenere
- Gronsfeld
- Vernam
Transposition & encoding
- Rail Fence
- Polybius Square
- Morse
- Huffman
Modern
- Blowfish
- RSA
Platform
- JavaScript
- Canvas 2D
- Tailwind CSS
- Firebase
Next case study
E-Doc