Data Encryption and Cryptography with Buddy

Cryptography: The use of carefully designed algorithms and keys to protect confidentiality, integrity, authenticity, or all three.

Buddy remains one of the best-known Clojure cryptography toolkits. That does not mean the hard part of cryptography is calling Buddy functions. The hard part is choosing the right primitive, protecting keys, rotating secrets, and making sure the application boundary uses the primitive for the right job.

Start by Choosing the Right Primitive

Different problems need different tools:

• encryption protects confidentiality
• hashing is for one-way transformation and fingerprinting
• password hashing is for credential verification with slow, attack-resistant schemes
• message authentication and digital signatures protect integrity and authenticity

One of the most expensive security mistakes is using encryption where hashing was needed, or using a fast general-purpose hash where password hashing was required.

Buddy Helps, But It Does Not Replace Key Management

Buddy gives you a practical API for common crypto operations. It does not solve:

• where the key came from
• who may decrypt
• how rotation works
• what happens after compromise
• how audit evidence is produced

That means Buddy should sit inside a wider security design, not become the entire plan.

Authenticated Encryption Should Be the Default Mental Model

If you encrypt application data, you usually want integrity protection too. Buddy’s high-level API supports authenticated schemes such as AES-GCM.

 1(ns myapp.crypto
 2  (:require [buddy.core.codecs :as codecs]
 3            [buddy.core.crypto :as crypto]
 4            [buddy.core.nonce :as nonce]))
 5
 6(defn encrypt-payload [plaintext key]
 7  (let [iv (nonce/random-bytes 16)
 8        ciphertext (crypto/encrypt
 9                     (codecs/to-bytes plaintext)
10                     key
11                     iv
12                     {:algorithm :aes256-gcm})]
13    {:iv iv
14     :ciphertext ciphertext}))
15
16(defn decrypt-payload [{:keys [iv ciphertext]} key]
17  (-> (crypto/decrypt ciphertext key iv {:algorithm :aes256-gcm})
18      (codecs/bytes->str)))

The example is intentionally small. In production, the key should come from a secret manager, KMS, HSM-backed workflow, or similarly controlled source, not from a hardcoded string.

Nonces, IVs, and Key Reuse Rules Matter

The most dangerous crypto bugs are often operational:

• nonce reuse with the wrong scheme
• one key used for too many unrelated purposes
• copying an example that uses a static IV
• storing encrypted blobs without enough metadata to rotate or reprocess them later

If the system encrypts real data, document:

• the algorithm
• the key source
• the IV or nonce strategy
• rotation expectations
• failure behavior when decryption breaks

Passwords Are Not General Encryption

Do not use general encryption APIs to “protect” passwords. Passwords should be verified with dedicated password-hashing libraries or delegated to an external identity system. Buddy’s broader crypto tools and password-hashing tools serve different problems.

Key Management Is the Real System Boundary

For most teams, the biggest improvement comes from key discipline:

• generate keys in a controlled system
• keep keys out of source control
• restrict which services may access them
• rotate on schedule and after incidents
• version the key identity used for each encrypted record when the design requires it

Good cryptography with weak key management becomes an expensive illusion of safety.

Common Failure Modes

Hardcoding Secrets or Master Keys

This turns encryption into a source-control problem.

Reusing One Key for Every Purpose

Signing, encryption, password handling, and token issuance usually need distinct lifecycles.

Confusing Encryption with Password Storage

Passwords should be verified, not reversibly encrypted for later recovery.

Copying Example IVs or Demo Keys into Production

Examples teach mechanics. Production needs managed randomness and real key ownership.

Practical Heuristics

Use Buddy as a focused Clojure crypto toolkit, but design the system around authenticated encryption, distinct key purposes, managed key sources, and explicit rotation rules. Encrypt only what needs confidentiality, hash only where one-way transformation is the goal, and never let convenience blur those boundaries. In Clojure, the strongest crypto code is usually small. The hard engineering work lives around it.

Ready to Test Your Knowledge?