Case study · 2024 to present
Cappu Crypt
The problem
There is a wide gap between projects that need encrypted data and projects that need a key management service. A hosted KMS brings key rotation policies, access control and a bill; rolling your own means a hardcoded key in a config file that nobody ever changes. Small projects usually take the second option, because the first one is more machinery than the problem deserves.
Cappu Crypt is the middle. It is one Spring Boot application with three endpoints: encrypt, decrypt, and delete a key. Post some content and it returns the ciphertext along with an ID; post the ID and the ciphertext back and it returns the plaintext. Keys are created on demand when no ID is supplied.
Encryption is AES in GCM mode at 128, 192 or 256 bits, with optional metadata carried for integrity checks. An authorization key gates the API, and a master key encrypts the stored keys, so the database on its own is not enough to read anything. It is deliberately shaped to sit on a back-facing server with no route in from outside.
Stack and tooling
| Language | Java 22 |
| Framework | Spring Boot 3.3 |
| Storage | PostgreSQL via Spring Data JPA |
| Deployment | Docker Compose or a JVM binary |
3
API endpoints
3
AES key sizes