Hell is overconfident developers writing encryption code

Tone and framing of “hell”

• Several commenters agree that writing crypto is dangerous for non-experts, but dislike framing “overconfident developers” as “hell”; they see it as demotivating rather than educational.
• Others defend the frustrated tone as understandable given how often the same mistakes reoccur.

Why developers roll their own

• Common complaint: experts are condescending, vague, or self-promotional (e.g., dropping a snarky GitHub issue plus a blog link but not explaining details).
• Identifying real experts vs. “windbags” is perceived as hard and time‑consuming; hiring them is expensive and rarely budgeted.
• Pressure to “ship yesterday” and security as a box‑ticking exercise pushes teams toward ad‑hoc solutions.

Using crypto correctly is hard

• Even when using libraries, many devs struggle with low‑level, footgun‑heavy APIs (OpenSSL, Node’s crypto), and the difficulty of composing primitives into secure protocols.
• Multiple people note you can misuse even high‑level libs like libsodium (bad keys, nonces, protocol design).
• Core theme: most real vulnerabilities come from “joinery” and protocol design, not from the primitive itself.

Examples of bad crypto

• Stories of partners reversing RSA public/private roles, limiting input to 8 bytes, or inventing bespoke XML “encryption” with hard‑coded, published RSA keys, often accepted because it “looks complex.”
• Discussion of padding‑oracle risks and unauthenticated CBC; concern that maintainers sometimes dismiss warnings when they don’t see an immediate exploit path.

What “don’t roll your own crypto” means

• One camp: it now effectively means “don’t do anything security‑related without experts,” which feels paralyzing.
• Counterpoint: the original intent is narrower—don’t design your own schemes or compose primitives (AES, RSA, DH, etc.) into new protocols without expertise; using audited high‑level constructs (“boxes”, AEAD, KMS, Vault) is fine.
• Debate about whether writing auth systems or password storage counts; consensus: primitives like salted SHA are out, password KDFs (bcrypt, scrypt, Argon2, PBKDF2) are table stakes, but full auth flows still have many pitfalls.

Tools, documentation, and responsibility

• Strong calls to prefer opinionated, misuse‑resistant libraries (libsodium, Tink, age, sops, managed KMS/Vault) and to get external review for anything novel.
• Several argue cryptographers have underdelivered on “easy‑to‑use, hard‑to‑misuse” tooling and accessible, centralized best‑practice documentation, contributing to developer mistakes.
• Others counter that crypto’s inherent complexity and incomplete threat models can’t be solved by simple checklists; the realistic path is better tooling plus occasional expert consultation.