Hell is overconfident developers writing encryption code

https://soatok.blog/2025/01/31/hell-is-overconfident-developers-writing-encryption-code/

by zdw • 1 year ago

201 238 1 year ago

Aeolun3• 1 year ago

The reason overconfident developers roll their own crypto is because the ‘cryptography experts’ are such asshats about it. Who wants to deal with someone that writes this?

Hell, even identifying which ‘cryptography expert’ actually knows what they’re talking about and which ones are windbags is often more trouble than it’s worth.

tptacek26• 1 year ago

I don't love the post either but getting angry about it doesn't make it less right.

Aeolun3• 1 year ago

I’m not exactly angry at it. Just pointing out the flaw in its argument.

It’s never worked to yell at my junior developers and tell them that ‘hell is them doing any kind of development’.

It works better when I just show them what they should do instead.

MarcelOlsz• 1 year ago

Hell, even identifying which ‘cryptography expert’ actually knows what they’re talking about and which ones are windbags is often more trouble than it’s worth.

If they look like they spent too much time in the sun you can't trust them. This criteria has yet to fail me.

YZF• 1 year ago

The more nuanced message is maybe don't write crypto code without having spent the right amount of time to understand the challenges. If you don't know about timing attacks, you aren't familiar with the many historical mistakes that are well known, you don't know any theory around ciphers or hashes, then you probably shouldn't be writing crypto code that is used to secure anything important. There are a lot of ways to get up to speed (Coursera's cryptography courses from Stanford, books etc.) to at least wrap your head around why this is a problem. Even the experts go through peer review cycles because they know how easy it is to make mistakes.

In other news, don't print yourself a motorcycle helmet on your 3d printer, don't make your own car tires, don't make your own break pads. I mean if you really know what you're doing maybe.

EDIT: I have some personal experience with screwing up some crypto code. I won't get into all the details but I was overconfident. And this was after taking graduate level cryptography courses and having spent considerable time keeping up to date. I didn't write anything from scratch but I used existing algorithms/implementations in a problematic way that left some vulnerability. This was a type of system where just using something off the shelf was not an option.

Aeolun3• 1 year ago

There are a lot of ways to get up to speed

None condoned by your employer however. Those tickets need finished yesterday. Security is just a checkmark.

hn_throwaway_99• 1 year ago

I just skimmed the article, but I generally agree. I mean, I get it - I think it's actually pretty easy to make an argument "Secure crypto code is exceedingly difficult to get right, even for experts. And unlike lots of other areas of code, there is no 'halfway broken' - crackable crypto is 'game over' in a lot of situations, which is why it's so dangerous to roll your own."

But there's a huge gulf between that message and "Hell Is Overconfident Developers..." And importantly, I don't think that "overconfident developers" is the biggest problem. If anything, even when I very much don't want to "roll my own" crypto, I've found it difficult to be sure I'm using crypto libraries correctly and securely. Sometimes libraries are too low-level with non-obvious footguns, or they're too "black box" restrictive. I think a great example is the NodeJS crypto library. I think it's a great library, but using it correctly requires people to know and understand a fair amount about crypto. Whenever I use node crypto I pretty much always end up writing some utility methods around it (e.g. "encrypt this string using a key to get cipherText" and "decrypt this ciphertext using this key"). I think it would be better if those standard utility wrappers (that do things like use recommended default encryption algorithms/strengths, etc.) were also included directly in the crypto library.

I think most developers are actually scared of rolling their own crypto, but cryptography experts don't make it easy to give them a plug-and-play solution.

Uptrenda2• 1 year ago

Based comment, updooted. Also, I'm pretty sure that if nobody ever "rolled their own crypto" we would never have new innovations in cryptography. By OPs argument everyone in the blockchain industry is in a state of error since using applied cryptography to design new protocols is certainly novel. But I would say that these protocols are what made me interested in applied cryptography in the first place. They are astonishingly clever, novel, and show how beautiful cryptography can be. If everyone was too scared to work with cryptographic constructs than none of the innovation that took place around smart contracts would be possible.

I see no problem with it if your work gets peer reviewed. The very last point they made though I kind of agree with. If you end up making a new algorithm from scratch that is dangerously novel and potential crack pot territory. I did like how they went to that trouble to make the hierarchy of what is meant by "rolling your own crypto."

oefrha• 1 year ago

I kept waiting for actionable advice, like maybe a site somewhere documenting the current best practices on common tasks, say securely implementing the complete lifecycle of encrypted sessions. Got to the end and it seems the advice, if there is one, is to pay some cryptography expert to review my system. And I have no idea if the author is a cryptography expert or an overconfident expert-wanna-be rolling their own crypto advice. So yeah, I agree.

Can HN give some actionable advice on dos, not don’ts (I already know all the don’t like don’t use OpenSSL primitives, don’t use AES-CBC, blah blah)?

fargle• 1 year ago

plenty of "cryptography experts" that you blindingly trust because "don't roll your own crypto" make giant, fatal, mistakes too. i love how the "crypto is so hard, even experts get it wrong" argument both supports the elitist POV and is apologist for when "even" the experts get it wrong.

crypto is like many other things in which if you make ONE TINY mistake you are doomed. point taken. do your due diligence. but also don't trust randos. or the NSA and probably NIST. therefore most so-called experts.

if hell is "overconfident" developers, then what is "overconfident experts". or "overconfident furry apologists for crypto experts"? also hell.

crypto is hard. we get it. you're also no better than anyone else at it.

tptacek26• 1 year ago

This is a relatively long post that is kind of beating around the bush: these developers believed that OpenSSL was a trustworthy substrate on which to build a custom cryptosystem. It's not; this is why libraries like Tink and Sodium exist. They don't really need much more lecturing than "stop trying to build on OpenSSL's APIs."

arthurcolle• 1 year ago

tptacek I don't want to waste your time, but do you have any good recommendations for material that bridges the gap between modern deployed cryptosystems and the current SOTA quantum computing world in enough detail that is useful for an engineer practitioner preparing for next 10 years?

tptacek26• 1 year ago

Nope. It's at times like these I'm glad I've never claimed I was competent to design cryptosystems. I'm a pentester that happens to be able to read ~30% of published crypto attack papers. My advice is: ask Deirdre Connolly.

My standard answer on PQC about about the quantum threat is: "rodents of unusual size? I don't think they exist."

jasonjayr2• 1 year ago

We were doing an integration with a partner for our customers, and the contact I was working with insisted on using some OpenSSL primitives that were exposed in PHP:

(a) they reversed the public + private parts of the key, and were upset when I communicated the public part of the key in cleartext

(b) they speced that the string being encrypted could not exceed 8 bytes ......

I tried so very hard and very patiently to explain to them what they were doing wrong, but they confidently insisted on their implementation. To deter fellow devs from trying this, I left loud comments in our code:

So these guys are totally using RSA Crypto wrong. Though it's a PK Crypto system, they insist on using it backwards, and using signatures to send us cateencrypted values, and we send encrypted values back to them. It's dumb. I suspect someone read through the PHP openssl function list, spotted RSA_encrypt_private and RSA_decrypt_public and decided to get overly clever.
This consumes a public key, and uses it to 'decrypt' a signature to recover it's original value.
To further deter use, I will not add additional documentation here. Please read and understand the source if you think you need to use this.

jiggawatts3• 1 year ago

Reminds me of a vendor providing an XML-RPC API with their enterprise product. The customer had a requirement that all PII information be encrypted in transit, and this was used used to send personal information about minors.

I expected them to simply turn on HTTPS like normal people.

Instead after months of effort they came back with XML Encryption. No, not the standardised one, they cooked up the their own bespoke monstrosity with hard-coded RSA keys with both the public and private parts published in their online documentation. The whole thing was base-64 encrypted XML inside more XML.

I flat rejected it, but was overruled because nobody involved had the slightest clue what proper encryption is about. It looked complicated and thorough to a lay person, so it was accepted despite my loud objections.

This is how thing happen in the real world outside of Silicon Valley.

tbrownaw• 1 year ago

The was at least also TLS on top of that, yes?

crabmusket• 1 year ago

The whole thing was base-64 encrypted XML

Surely you mean "base64 encoded"

77pt77• 1 year ago

[flagged]

Volundr• 1 year ago

they reversed the public + private parts of the key

Is there a reason this is actually a problem? I always thought the public/private key was arbitrary and it was easier and less error prone to give people one key called public and one called private than hand them two keys and say "ok keep one of these a secret".

Don't get me wrong, not defending anyone here, just curious is there's more to it I don't know.

curling_grad• 1 year ago

I'd assume that the value intended for public exponent is used as private key exponent. Typically, public key exponent is very small compared to private key exponent. This means that the private key exponent is very small in their scheme, so attacks such as Wiener's attack[0] can be used to break the encryption.

Also, I'd like to add that public exponent is usually fixed to some well-known constant such as 65537, so the attacker might just try brute-forcing when she knows the details of the scheme.

[0] https://en.wikipedia.org/wiki/Wiener%27s_attack

jcalvinowens• 1 year ago

That's not generally true: typically you can compute the public key from the private key, but not vice versa (i.e. crypto_scalarmult_base() in libsodium).

In RSA, that isn't possible (without assumptions), so a private key file also contains the public key data.

jasonjayr2• 1 year ago

Honestly, I don't know. And as a non-expert on all things crypto, I delegate my trust into the labels that the expert do assign things. There may be a weakness in the algorithm if the keys are reversed, that is not immediately obvious. If the thing we're protecting is worth protecting, it's worth doing it right...

Sytten2• 1 year ago

I didnt understand the point he was trying to make about trusting a public key from a remote server. At somepoint you need to trust some third party public key if you want to send them encrypted data and verifying ownership is kinda left to user. Hell even signal does that, who is really checking their contact security numbers to make sure the signal server didnt send you some bullshit...

some_furry12• 1 year ago

didnt understand the point he was trying to make about trusting a public key from a remote server.

What stops the server from swapping SyttenPK for NSA PK?

The operating word of the quote was "just".

Hell even signal does that, who is really checking their contact security numbers to make sure the signal server didnt send you some bullshit...

Their latest code commits include key transparency, which is one good way to address this problem.

Sytten2• 1 year ago

I do get that, but I am not so sure what the real solution is. The industry standard still is some form of "the server sends me a key and I trust it".

Key transparency is not really solving anything for the average person.

voxelc4L• 1 year ago

… or any code?

devmor• 1 year ago

s/Encryption/Security

Roll-your-own cryptography is definitely the worst of it, but even developers that use strong crypto libraries end up misusing them quite often.

I have worked on a lot of custom made web software, and I could count the number of in-house authentication or authorization systems that didn't have glaring issues on one hand.

After nearly 12 years of working in this field, I would consider myself extremely knowledgeable in web security and I still don't think I'd be comfortable writing a lot of these types of systems for production use without an outside analyst to double check my work. Unless you're a domain expert in security, you probably shouldn't either.

userbinator• 1 year ago

The insecurity is freedom. Think of that again when you need to break out of Big Tech's control.

tptacek26• 1 year ago

What? Say more.

saurik• 1 year ago

Big tech often uses cryptography to lock us out of our own hardware and into their DRM schemes, hiding what the software on the device is doing and often even hiding the binaries. Updates to the software become ways to more often protect the company's business models than to protect the user, and so "bugs become features" in this regime, leading to perverse incentivizes among everyone aware enough to understand this dynamic, with end users encouraging each other to NOT accept security updates in the HOPE that they will be broken one day in order to finally have a way to get root access on their own device. I recommend watching some of the many talks I have given on this subject or reading some of the many articles written by Cory Doctorow, if you somehow honestly don't know about this dynamic. When someone at Big Tech stupidly reimplements crypto... we cheer.

https://youtu.be/WyBgn06LNOY

Dibby053• 1 year ago

The post links to this GitHub issue [1] where the critic explains his issues with the design and the programmer asks him to elaborate on how those crypto issues apply to his implementation. The critic's reply does not convince me. It doesn't address any points, and refers to some vague idea about "boring cryptography". In what way is AWS secrets manager or Hashicorp Vault more "obviously secure" than the author's 72-line javascript file?

[1] https://github.com/gristlabs/secrets.js/issues/2

rendaw2• 1 year ago

And the critic's only argument is a link to their own blog...

hatf0• 1 year ago

Those aren’t even the correct answer for the use-case in question, anywho. What they’re looking for would actually be sops (https://github.com/getsops/sops), or age (made by the fantastic Filo Sottile: https://github.com/FiloSottile/age), or, hell, just using libsodium sealed boxes. AMS KMS or Vault is perhaps even worse of an answer, Actually

maqp8• 1 year ago

It doesn't address any points

Taking some time to point out the vulnerability is already charity work. Assuming that's also a commitment to a free lecture on how the attacks work, and another hour of free consultation to look into the codebase to see if an attack could be mounted, is a bit too much to ask.

Cryptography is a funny field in that cribs often lead to breaks. So even if the attack vector pointed out doesn't lead to complete break immediately, who's to know it won't eventually if code is being YOLOed in.

The fact the author is making such a novice mistake as unauthenticated CBC, shows they have not read a single book on the topic should not yet be writing cryptographic code for production use.

LPisGood2• 1 year ago

Taking some time to point out the vulnerability is already charity work

Sure, but if you’re not going to reason why the vulnerability you’re pointing out is an issue or respond well to questions then it’s almost as bad as doing nothing at all.

A non expert could leave the same Maintainers on many Github pages. Developers can’t be expected to blindly believe every reply with a snarky tone and a blog link?

SomaticPirate• 1 year ago

Wow, the smugness of that reply. Responding by calling someone naive and blowing them off despite there being real questions.

The “insecure crypto “ that they clearly link to (despite not wanting to put them on blast) was also a bit overdone. I guess we all are stuck hiring this expert to review our crypto code(under NDA of course) and tell us we really should use AWS KMS.

BigJono• 1 year ago

AWS KMS is great product branding. I've never seen another company so accurately capture how it feels to use their product with just the name before.

benmmurphy• 1 year ago

There are some weird attacks against KMS that I think are possible that are not obvious. For example KMS has a mode where it will decrypt without supplying a key reference (suspicious!). If an attacker can control the cipher text then they can share a KMS key from their AWS account to yours and then control the plaintext. I haven’t confirmed this works so maybe my understanding is incorrect.

Also, with KMS you probably should be using the data key API but then you need some kind of authenticated encryption implemented locally. I think AWS has SDKs for this but if you are not covered by the SDK then you are back to rolling your own crypto.

block_dagger• 1 year ago

I agree with his comment and would like to add that the critic came across as rude and superior. Instead of answering the dev’s question in good faith, they linked to their own blog entry that has the same tone. Is it a cryptographic expert thing to act so rude?

1970-01-013• 1 year ago

Great question. AWS secrets and Hashicorp Vault have both been audited by a plethora of agencies (and have passed). GitHub code for someone's pet project very likely isn't going to pass any of those audits. When something goes wrong in prod, are you going to point your copy of 'some JS code that someone put on the Internet' and still have a job?

https://docs.aws.amazon.com/secretsmanager/latest/userguide/...

https://www.hashicorp.com/trust/compliance/vault

bagels2• 1 year ago

Yeah, many probably wouldn't get fired for that, but small consolation for a breach.

amluto• 1 year ago

The criticism in that issue is pretty bad, I agree. But the crypto in secrets.js is all kinds of bad:

The use case is sometime calling this tool to decrypt data received over an unauthenticated channel [0], and the author doesn’t seem to get that. The private key will be used differently depending on whether the untrusted ciphertext starts with '$'. This isn’t quite JWT’s alg none issue, but still: never let a message tell you how to authenticate it or decrypt it. That’s the key’s job.

This whole mess does not authenticate. It should. Depending on the use case, this could be catastrophic. And the padding oracle attack may well be real if an attacker can convince the user to try to decrypt a few different messages.

Also, for Pete’s sake, it’s 2025. Use libsodium. Or at least use a KEM and an AEAD.

Even the blog post doesn’t really explain any of the real issues.

[0] One might credibly expect the public key to be sent with some external authentication. It does not follow that the ciphertext sent back is authenticated.

rendaw2• 1 year ago

But having bad crypto doesn't mean you have to be aggressive... in fact if the critic's goal is to actually improve the situation (and not just vent or demonstrate their superiority) then being polite and actually answering the questions might go a long way further to remedy it.

jhack• 1 year ago

Don't forget to rand(rand()).

TheCleric• 1 year ago

I think one of the reasons developers roll their “own” crypto code is because there doesn’t really seem like a simple “do it this way” way to do it. OpenSSL has hundreds of ways of doing encryption. So it almost has pitfalls by default, because of the complexity of the choices.

maqp8• 1 year ago

OpenSSL is not misuse resistant, nor is it opinionated.

Opinionated means the ciphers available are the best of the bunch. Misuse resistance means the API validates parameters and reduces the footguns.

If you're doing a closed ecosystem, you'll want both. Use something like libsodium, or it's higher level wrappers. For this the team should have decent understanding of the primitives of that high level library to e.g. know that insecurely generated keys are still accepted so you'll have to use a CSPRNG.

If you're having to interact with other systems that only support e.g. TLS, you'll want to have the company hire a professional cryptographer with focus on applied cryptography to build the protocol from lower level primitives. Other programmers should refuse to do this work, like non-structural-engineers refuse to do structural engineering because they know they'll be held responsible for doing work they're not qualified.

asciii• 1 year ago

I did not learn a single thing from this article. I did learn quite a bit from the programmer's stuff and situation.

biimugan• 1 year ago

Only tangential to this post, but if you need a way to share secrets with your teams (or whoever), Hashicorp Vault is pretty decent. They don't even need login access. Instead of sharing secret values directly, you wrap the secret which generates a one-time unwrapping token with a TTL. You share this unwrapping token over a traditional communication method like Slack or e-mail or whatever, and the recipient uses Vault's unwrap tool to retrieve the secret. Since the unwrapping token is one time use, you can easily detect if someone intercepted the token and unwrapped the secret (by virtue of the unwrapping token no longer working). This hint tells you the secret was compromised and needs to be rotated (you just need to follow-up with the person to confirm they were able to retrieve the secret). And since you can set a TTL, you can place an expectation on the recipient too -- for example, that you expect them to retrieve the secret within 10 minutes or else the unwrapping token expires.

All of this has the added benefit that you're not sharing ciphertext over open channels (which could be intercepted and stored for future decryption by adversaries).

nejsjsjsbsb• 1 year ago

I like this. Can you add yubikey as another factor?

Where I work we never need this though, we have a jwt server that can serve a time limited token for work account that various systems can accept.

programmarchy• 1 year ago

Glad to hear this. I’m planning to use Vault in a new project that has sensitive security concerns. I liked Hashicorp’s concept of “encryption as a service” as a way of protecting engineering teams from cryptographic footguns.

1970-01-013• 1 year ago

It really needs to be taught in comp sci classes at this point. Have an entire project dedicated to why rolling your own crypto is at best a waste of time. Students will listen if they need to pass a test on it.

AlotOfReading4• 1 year ago

Giving people more introduction to crypto is a good way to get more handwritten crypto. It's part of the fun family of purely mathematical algorithms, alongside hashes, RNGs, and checksums. People make essentially the same mistakes in all of these.

necovek• 1 year ago

Do you not want to train some of those students to write the improved cryptography of the future?

I do agree having a project where you demonstrate problems they introduced (by exploiting them directly, or have another student team be the exploiters) would highlight the risks, but school is about teaching, not about scaring people off.

borski3• 1 year ago

That’s what the actual crypto classes are for. If people are intrigued, those are fantastic elective courses.

tombert• 1 year ago

Nah, hell is being stuck writing Kubernetes configs.

quotemstr• 1 year ago

I'm not sure the way to get developers to stop writing their own crypto is to turn it into a delicious forbidden fruit edible only by the most virtuous. APIs sometimes have a "Veblen good" character to them: the more difficult, the more use they attract, because people come to see use of the hard API as a demonstration of skill.

The right way to stop people writing their own cryptography isn't to admonish them or talk up the fiendish difficulty of the field. The right way to make it boring, not worth the effort one would spend to reinvent it.

umvi5• 1 year ago

What does "don't build your own crypto" even mean any more?

I originally thought it meant "don't implement AES/RSA/etc algorithms yourself"

But now it seems to mean "pay auth0 for your sign in solution or else you'll definitely mess something up"

As an example, we have a signing server. Upload a binary blob, get a signed blob back. Some blobs were huge (multiple GB), so the "upload" step was taking forever for some people. I wrote a new signing server that just requires you to pass a hash digest to the server, and you get the signature block back which you can append to the blob. The end result is identical (i.e. if you signed the same blob with both services the result would indistinguishable). I used openssl for basically everything. Did I roll my own crypto? What should I have done instead?

LPisGood2• 1 year ago

Cryptographic protocols are algorithms built on cryptographic primitives and they have plenty of footguns.

EE84M3i• 1 year ago

Now it's possible for someone to ask the server to sign a blob that they only know the hash of. Is that an issue in your threat model? No idea.

magicalhippo• 1 year ago

I feel threat modelling is the really difficult part in gluing together known-good crypto parts into a solution.

I've glued together crypto library calls a few times, and I've implemented RFCs when I've done so, like HKDF[1].

But that isn't enough if the solution I've chosen can easily be thwarted by some aspect I didn't even consider. No point in having a secure door lock if there's an open window in the back.

[1] https://www.rfc-editor.org/rfc/rfc5869

pclmulqdq8• 1 year ago

It used to mean "use AES instead of rolling your own form of symmetric encryption." Then it became "use a library for AES instead of writing the code." It has now reached the obvious conclusion of "don't do anything vaguely security-related at all unless you are an expert."

tptacek26• 1 year ago

No it hasn't. The subtext of "don't roll your own crypto" is that "AES" doesn't do, by itself, what most developers think it does; there's a whole literature of how to make AES do anything but transform 16 unstructured bytes into 16 different bytes indistinguishable from random noise; anything past that, including getting AES to encrypt a string, is literally outside of AES's scope.

The shorter way of saying this is that you should not use libraries that expose "AES", but instead things like Sodium that expose "boxes" --- and, if you need to do things that Sodium doesn't directly expose, you need an expert.

Contra what other people on this thread have suggested, reasonable security engineers do not in fact believe that ordinary developers aren't qualified to build their own password forms or permissions systems; that's a straw man argument.

smolder10• 1 year ago

The stuggle was real in the early web with getting companies to do proper password storage and authentication but the fact that seasoned professionals turn to auth0 or okta (and have been bitten by this reliance!) nowadays strikes me as a little embarrassing.

brianstrimp• 1 year ago

And the consequence is that people get banged on the head if they either use sth existing (cause they will be using it wrong) or they build sth on their own (because that's obviously bad) or they get fed up and don't use anything.

The issue with security researchers, as much as I admire them, is that their main focus is on breaking things and then berating people for having done it wrong. Great, but what should they have done instead? Decided which of the 10 existing solutions is the correct one, with 9 being obvious crap if you ask any security researcher? How should the user know? And typically none of the existing solutions matched the use case exactly. Now what?

It's so easy to criticize people left and right. Often justifiably so. But people need to get their shit done and then move on. Isn't that understandable as well?

harrall• 1 year ago

I feel like there is a huge subset of people who just do trial and error programming. The other day, I watched a whole team of 8 people spend a whole work day swapping out random components on Zoom to diagnose a problem because not a single person considered attaching a debugger to see the exact error in 5 minutes.

I feel like you have to tell people to not roll your own whatever because there are so many of these types of people.

hoilmic• 1 year ago

What should I have done instead?

Security has largely to do with trust.

When asked who I trust most in this space, the answer is always libsodium.

I leave as much of the protocol as possible to their implementation.

https://doc.libsodium.org/

unscaled4• 1 year ago

The sad truth is that even libsodium can be misused (and the article explicitly mentions that twice). Even pretty high-level constructions like libsodium's crypto_secretbox can be misused, and most of the constructs that libsodium exposes are quite low-level: crypto_sign_detached, crypto_kdf_hkdf, crypto_kx, crypto_generichash.

I think we should understand and teach "do not roll your own crypto" in the context of what constructs are used for what purposes.

AES is proven to be secure and "military-grade" if you need to encrypt a block of data which is EXACTLY 128 bit (16 bytes) in size. If you want to encrypt more (or less) data with the same key, or make sure that the data is not tampered with or even just trust encrypted data that passes through an insecure channel, then all bets are off. AES is not designed to help you with that, it's just a box that does a one-off encryption of 128 bits. If you want do anything beyond that, you go into the complex realm of chaining (or streaming) modes, padding, MACs, nonces HKDFs and other complex things. The moment you need to combine more than two things (like AES, CBC, PKCS#7 padding and HMAC-SHA256) in order to achieve a single purpose (encrypting a message which cannot be tampered), you've rolled your own crypto.

Libsodium's crypto secretbox is safe for encrypting small or medium size messages that will be decrypted by a trusted party that you share a securely-generated and securely-managed key with. It's far more useful than plain AES, but it will not make any use case that involves "encryption" safe. If you've decided to generate a deterministic nonce for AES, or derive a deterministic key (the article links a good example[1]), then libsodium will not protect you. If you attempt to encrypt large files with crypto_secretbox by breaking them to chunks, you will probably introduce some vulnerabilities. If you try to build an entire encrypted communication protocol based on crypto_secretbox, then you are also likely to fail.

The best guideline non-experts can follow is the series of Best Cryptographic Answers guides (the latest one I believe is Latacora 2018[1]). If you have a need that is addressed there and you only need to use the answer given with combining it with something else, you're probably safe.

Notice that the answer for Diffie-Hellman is "Probably nothing", since you're highly unlikely to be able to use key exchange safely in isolation. I did roll key exchange combined with encryption once, and I still regret it (I can't prove that thing is safe).

The "You care about this" part explains the purpose of each class of cryptographic constructs that has a recommendation. For instance, for asymmetric encryption it says "You care about this if: you need to encrypt the same kind of message to many different people, some of them strangers, and they need to be able to accept the message asynchronously, like it was store-and-forward email, and then decrypt it offline. It’s a pretty narrow use case."

So this tells you that you probably should not be using libsodium's crypto_box for sending end-to-end encrypting messages in your messaging app.

[1] https://www.latacora.com/blog/2018/04/03/cryptographic-right...

[1] https://www.cryptofails.com/post/75204435608/write-crypto-co...

smolder10• 1 year ago

I honestly think it's a meme born of propaganda. 'Don't roll your own' is good advice a lot of the time when there are hardened libraries at your disposal, but who does it serve if less people know how to build useful cryptography? Three letter agencies mostly. I had no trouble implementing useful algorithms in college as part of my study of it, or understanding different potential weaknesses like timing or known plaintext attacks. We didn't cover side channels like power analysis but how often does that actually matter outside of a lab?

xvector5• 1 year ago

No, you can not competently roll your own crypto because you took an algorithms class in college. Even the assumption you could is absurd.

tptacek26• 1 year ago

The fact that you're referring to useful algorithms here is kind of a "tell", for what it's worth. "Known plaintext attacks" are not a broad class of vulnerability in cryptosystems; they're a setting for attacks. It's like saying "I've studied the browser security model including weaknesses such as the same origin policy".

scott_w5• 1 year ago

Learning crypto isn’t just a box ticking exercise that you learn it and now you’re qualified to “do crypto” for the rest of your career. I also studied this in university but I know that I don’t spend anywhere near enough time to day to avoid, well, any pitfalls of rolling my own crypto.

I currently work on our company’s Auth systems and half my team still side-eyes our own work, despite having worked on this area for years now.

Ekaros2• 1 year ago

With signing server level of interaction is the thing that really matters. I would probably say that if you implemented algo doing the signing operation it might be questionable. But if you implemented the key storage fully yourself, it is even more questionable. Or design your HSM module, or just write the keys in plaintext or minimally protected on the disk...

Also who designed and implemented checking the appended blob? Also crypto...

tptacek26• 1 year ago

It never meant "don't implement AES/RSA yourself". Nobody sane does that; there has never been a need to convince people not to write their own implementations of AES. Ironically, doing your own AES is one of the less-scary freelancing projects you can undertake. Don't do it, but the vulnerabilities you'll introduce are lower-tier than the ones you get using OpenSSL's AES.

It has, always, mean "don't try to compose new systems using things like AES and RSA as your primitives". The serious vulnerabilities in cryptosystems are, and always have been, in the joinery (you can probably search the word "joinery" on HN to get a bunch of different fun crypto vulnerabilities here I've commented on).

Yes: in the example provided, you rolled your own cryptography. The track record of people building cryptosystems on top of basic signature constructions is awful.

hyperman12• 1 year ago

I assume you've never seen AES written in vbscript? Generally, the thought process goes: This thing needs AES, I want to talk to it, I know $language, and wikipedia has the algorithm. The idea that AES is there for a reason ( like security) never enters the thought process.

Someone is building a shed, not a whole building, and stopped listening to real builders with their nitpicky rules long ago. It works great, until the shed has grown into a skyscraper without anybody noticing, and an unexpected and painfull lesson about 'load bearing' appears.

umvi5• 1 year ago

So... you've pointed out the problems, what are the solutions?

What am I allowed to use as primitives to compose systems that require cryptographic functionality? If I'm writing medical device software and the hospitals I'm selling to say I can't store files in plaintext on disk, but also some security expert on HN says I shouldn't use AES as a piece of the solution because that's "rolling my own crypto" and too dangerous, what should I do? Mandate that postgres configured with encryption be used (even if the application is simple and doesn't require a full db)? That will almost certainly harm the prospect of the sale because having to get hospital IT involved introduces a lot of friction. Or are you saying "use sodium to encrypt the file, don't try to do it yourself with AES"?

loeg3• 1 year ago

I want to roll my own variant of AES (I know, I know!) CTR mode for appendable (append-only) files that does not require a key change or reencrypting any full AES block. Big caveat, this design doesn't have a MAC, with all the associated problems (it's competing against alternatives like AES-XTS, not authenticated modes).

Partial blocks are represented by stealing 4 bits of counter space to represent the length mod block size. This restricts us to 2^28 blocks or about 4GB, but that's an ok limitation for this use.

So say you initially write a file of 33 bytes: two full blocks A and B, and a partial block C. A and B get counter values 0 (len) || 0 (ctr) and 0 (len) || 1 (ctr). C is encrypted by XORing the plaintext with AES(k, IV || 1 (len) || 2 (ctr)).

You can append a byte to get a length of 34 bytes. Encrypted A/B don't change. C_2 is encrypted by XORing plaintext_2 with AES(k, IV || 2 (len) || 2 (ctr)). Since the output of AES on different inputs is essentially a PRF, this seems... ok?

Finally if you append enough bytes to fill C, it gets to len=0 mod 16. So the long and short if it is: no partial or full block will ever reuse the same k+iv+len+ctr, even rewriting it for an append.

ozim2• 1 year ago

Building crypto systems is also hard.

You write about passing hash digest.

Makes me think about pass the hash vuln in windows NTLM where if someone grabs the hash they don’t need to know the pass anymore because they can pass the hash.

The same you still can use AES or RSA incorrectly so that whatever you built on top of those is vulnerable if you don’t have experience.

OK TFA explains all I have the same view on topic as author.

z3t42• 1 year ago

building your own crypto is so simple a 5 year old can do it, just roll a dice, and write down the numbers, those numbers are the key. Then convert the text to numbers, and for each letter add the corresponding key number, and the sum will be the encrypted text. To decrypt you subtract the number with the corresponding number on the key. The problem is that modern crypto is so complicated one will easily make an error implementing it.

smitelli2• 1 year ago

That works if your key is long as heck, or the message is short as heck. Still, a useful way to quietly entertain (some) kids for a little while.

olddustytrail• 1 year ago

In that scheme -5 is always A and there are only 6 options for any particular letter, so you can do a slightly more complicated frequency analysis.

Sounds like it might be good for kids learning how to break crypto?

philjohn• 1 year ago

There's a load of places you can shoot yourself in the foot, e.g., not using constant time comparison functions, which leaves you open to timing attacks.

nazgul17• 1 year ago

Glueing together secure pieces too often does not result in a secure whole. People spend careers coming up with secure protocols out of secure pieces.

My take on not rolling your crypto is to apply as close to zero cleverness as possible when it comes to crypto. Take ready made boxes, use them as instructed and assume that anything clever I try to build with them is likely not secure, in some way or another.

foobarkey• 1 year ago

I know people want to get paid but 90% of crypto is just about making sure the thing takes constant time, please stop acting like it is some elite knowledge

AlotOfReading4• 1 year ago

I have an entire crypto book on my shelf that only mentions constant time once in an offhand paragraph about timing attacks. They managed to write the rest of the book on the other 99% of crypto.

RainyDayTmrw• 1 year ago

I have empathy for people who end up stuck in the in-between areas, where out-of-the-box building blocks solve part of their problem, but how to glue them together can still get tricky.

For one example, you've got a shared secret. Can you use it as a secret key? Do you have to feed it through a KDF first? Can you use the same key for both encryption and signing? Do you have to derive separate keys?

erinaceousjones2• 1 year ago

I'm in that boat. I'm watching all of Christoph Paar's cryptography lecture series on YouTube -- it was recorded in 2010, so I do wonder if it's missing any new state of the art / best practises.

I'm like 18 lectures in, two out of three semesters. And I still feel like I have only the vaguest ideas what the primitives are, how they work, what they're for, and their weaknesses. I'm having to follow all the mathematics as someone not mathematically inclined (Prof Paar did do a good job of making the mathematics fairly accessible though).

All of this so I can have a bit more confidence in proposing E2E for a project at some point in future (before somebody asks us to, too late).

And my use-case makes it difficult to follow the most trodden paths so I can't just plug in a handshake protocol and MACs and elliptic curves or "just use PGP" or whatever.

As a software dev, I have all these boxes I could use, that come with so many caveats "if you do this, but don't do this, no do that, don't do that"... It's very tricky trying to work out how to glue the pieces together without already being in the field of crypto. Feels like I'll always be missing some crucial piece of information I'd get if I pored over hundreds of textbooks and papers but I don't have the resources to do so!

I'd love if someone did like, a plain English recipe book for cryptography! Give the mathematical proof of stuff, but also explain the strengths/weaknesses/possible attacks to laypeople without the prerequisite that you need to understand ring modulus or Galois fields or whatever first. Or, like, flowcharts to follow!

maqp8• 1 year ago

so I do wonder if it's missing any new state of the art / best practises.

https://nostarch.com/serious-cryptography-2nd-edition should have the latest info, it's approachable and goes into pitfalls. https://www.manning.com/books/real-world-cryptography is another.

As a software dev, I have all these boxes I could use, that come with so many caveats "if you do this, but don't do this, no do that, don't do that"... It's very tricky trying to work out how to glue the pieces together without already being in the field of crypto

Until you know more, strongly consider suggesting the company just hires someone who knows that. Just because you're available to do it, doesn't mean you should just yet.

max_• 1 year ago

The reason why cryptography is so bad.

Is this elitist culture in cryptography.

Alot of algorithms are described incomprehensively.

Let me give you an example.

You might get a well documented specification for implementation of ECDSA.

But it will lack something very 2 important concepts.

1. You should only use it with "safe curves"

2. It's does provide you with a list of "Safe curves"

Same goes for Shamir Secret Sharing. You can know how to implement the algorithm.

But there is so much extra "insider knowledge" or "tribal knowledge" that isn't obvious to non-cryptographers, that you need, for it to be secure.

Such knowledge is often (if not always) not documented. It's in obscure forums, papers and blog posts like this one.

There is no comprehensive encyclopedia for cryptography algorithms.

Developers write bad encryption code because cryptographers have bad documentation.

I would blame the cryptographers, not the developers.

cowsaymoo• 1 year ago

What a coincidence! I was just browsing the Shamir's Secret Sharing Wikipedia page 30 seconds ago. There is a python implementation on it and I was worried the same exact thing as you before opening HN. So maybe we could start with that one. Is that code implementation sufficiently secure and well documented?

https://en.wikipedia.org/wiki/Shamir's_secret_sharing?wprov=...

some_furry12• 1 year ago

https://zkdocs.com has a whole chapter on Shamir's Secret Sharing.

(Ironically, this stuff is documented, cryptographers just aren't good at marketing.)

https://www.zkdocs.com/docs/zkdocs/protocol-primitives/shami...

cassonmars• 1 year ago

No, it is not.

The arithmetic used is not constant time, meaning the actual computational steps involved leak information about the secret, were either the recombination of the shares or the initial splitting were observed via side channels.

The arithmetic does not guard against party identifiers being zero or overflowing to zero, although it is not likely to occur when used this way.

tptacek26• 1 year ago

I don't understand what "blaming" the cryptographers gets you. Your system is either secure or it isn't. If you ship something insecure, that's on you.

AlotOfReading4• 1 year ago

There's definitely degrees of security that I'm having to constantly remind our security folks of when they aren't forced to deal with the costs of having expensive threat models.

dns_snek• 1 year ago

"Blame" isn't the most productive way to frame the conversation, but as GP mentioned, there aren't many resources for developers to learn about cryptography. We're in desperate need of comprehensive resources that can (at a minimum) help us answer:

1. Has this problem been solved using a proven cryptographic protocol? Which guarantees does this protocol offer? What are all the important considerations?

2. What's the next closest thing?

3. Can we safely modify the protocol in any way to accommodate our use case, and what are some common pitfalls?

Some people will ignore all that advice and do dumb things anyway, but if we want systems to be more secure, it's on cryptographers to make cryptography more approachable and on developers to actually listen when they do.

alfiedotwtf• 1 year ago

It's not insider knowledge, it's just the collective experience people have built up over time after discovering issues with classes of ciphers. It would be nice to have a standard checklist that everyone could refer to (think OWASP Top Ten) while reviewing a cryptosystem.

ikiris• 1 year ago

The checklist is really simple: did you use a verified product or did you try to roll your own and fail?

maqp8• 1 year ago

Cryptography isn't like that, it doesn't boil down to 10 simple steps. If you want ten, it's happening at higher level

1. Never invent your own primitives. Only professional cryptographers do that in algorithm competitions like AES, SHA-3, or PHC.

2. For interoperability, use BoringSSL, LibreSSL etc. Hire developer who knows how to do this. Or, hire a professional applied cryptographer to build TLS from low level primitives if you have a reason it's needed.

3. For closed ecosystems, use opinionated, misuse-resistant, high level libraries like libsodium, or libraries binding to it https://libsodium.gitbook.io/doc/bindings_for_other_language...

4. Use kernel CSPRNG to generate all secrets.

5. Have the implementation audited by professionals. E.g. Kudelski Security or NCC Group.

6. Have a bug bounty program that compensates well, and that allows disclosure of the attack.

7. If you're in a market where the competition has open source clients, you should have an open source client too, so that anyone can verify your cryptography is correctly implemented.

8. Keep anything that's WIP, under "research prototype, do not use in production" banner. That's not a cone of shame. If Dan Boneh can do it (https://crypto.stanford.edu/balloon/), so can you.

9. Realize that 90% of the work in cryptography is key management. Use OS keyring when possible.

10. Deploy end-to-end encryption everywhere you can. Data is a toxic asset. https://www.schneier.com/blog/archives/2016/03/data_is_a_tox...

So yeah, sorry, no "Use XChaCha20-Poly1305 or AES-GCM only", or "Use X25519/ed25519" or "remember to hash the X25519 shared secret". That's too in-depth for a ten point list. At that level, it's more of a top-ten book list.

maqp8• 1 year ago

Is this elitist culture in cryptography.

It's elitist in the same way quantum physics, string theory and molecular biology are. A hard science with lot's of moving parts not everyone can manage.

But there is so much extra "insider knowledge" or "tribal knowledge" that isn't obvious to non-cryptographers, that you need, for it to be secure.

Misuse-resistant cryptography is an open research problem. Claiming it's "tribal knowledge" makes it seem nefarious. Academics are not always good teachers, and collecting all the lessons from all papers you read into a book, is time away from doing more research that advances your career.

Such knowledge is often (if not always) not documented. It's in obscure forums, papers and blog posts like this one.

You can pay for the papers, and you can pay for the school to learn to understand those 'obscure' papers. Or you can hire someone who has done that. If you're a developer expected to implement algorithms of theoretical physics, you're not complaining about the papers being obscure, you're hiring a physicist with double-major in computer science.

There's way too much frustration towards cryptographers, and way too little frustration towards bad hiring practices, and incorrectly assigned work.

markus_zhang• 1 year ago

My optimistic opinion is that since our information is being leaked left and right, it doesn't matter whether we roll the algo by ourselves or not. Might as well do it for practice...

Quote from the Honorable MI5 head:

I mean, with Burgess and Maclean and Philby and Blake and Fuchs and the Krogers... one more didn't really make much more difference.

m3kw9• 1 year ago

Just add 2 to each char.

sureglymop2• 1 year ago

My question is, why does the library even support AES-CBC? I know that it's OpenSSL here but why can't we have an additional library then that ships only the recommended encryption schemes, safe curves, etc. and deprecates obsolete practices in an understandable process? Something that is aimed at developers and also comes with good documentation on why it supports what it does.

Ekaros2• 1 year ago

Legacy. You rarely only touch new stuff or secure stuff. And instead end up at least with one scenario that requires you do something with old stuff. And this is not just crypto.

sureglymop2• 1 year ago

I get that. But then, keeping that legacy stuff running is just as problematic as rolling your own crypto. We can leave OpenSSL as it is but it shouldn't be the popular recommendation for developers.

They should have another library which, like I said, actively deprecates obsolete and insecure practices but in a way that makes the update process digestible for people depending on it.

izacus2• 1 year ago

Because such library is pretty useless in the real world where your system needs to interact with other systems using "legacy" encryption schemes.

Usability and practicality is critical for successful security approach.

ExoticPearTree• 1 year ago

I think what the author implies is that people should use trusted and vetted crypto libraries, and rollout their own encryption primitives based on some documentation they read from who knows where.

Look at OpenSSL for example, even though the people who work on the project know a lot about crypto, they still make big mistakes. Now imagine the average developer trying to build crypto from scratch.

ethin2• 1 year ago

I... Don't really understand where to draw the line here. I'm not one to write AES implementations or something. But I did write a Noise implementation in C++ [1]. Does that count as "rolling my own crypto", even though I did my best to follow the Noise specification to the letter and used an audited cryptographic implementation? And the only reason I did that is because there wasn't such an implementation for C++. I won't deny that I'm not an expert of cryptography, but I think this article is a bit extreme, at least from my reading. We can't always use "off the shelf" implementations of everything, because maybe one doesn't exist, or one exists but it has no license (there are surprisingly a lot of these on GitHub), or it has a license incompatible with your projects license, and so on and so forth. But hey, what do I know? [1] https://github.com/ethindp/noise-cpp

AgentME• 1 year ago

I think I interpret the phrase "don't roll your own crypto" as expanding out to something like "don't roll your own crypto unless you're willing and able to prioritize solving any vulnerabilities that people report to you". Someone who is porting a well-regarded cryptography codebase by carefully going through all of the relevant code and matching all of its intentional behavior has a credible claim they're part of the exception.

People who have put in the time to learn the common failure modes of cryptography attempts and how to solve them could make the claim they're in the exception to some degree. Someone who can't imagine how they would begin evaluating a report about something like "ciphertext malleability" shouldn't.

ethin2• 1 year ago

I mean fair enough I suppose? I've always gone with the idea that "don't roll your own crypto" meant not implementing cryptographic building blocks. Which is reasonable and fair. I just take issue with it being something you'd apply to all crypto code.

Uptrenda2• 1 year ago

Yeah, devs aren't meant to roll their own crypto (tm) but most open source libraries for doing crypto are dangerous (and lack clear guide lines for using them.) So then, what do you expect people to do? OpenSSL is hugely over complicated and hard to use. Having it as a dep almost certainly means breaking your software at some point, too. Libsodium is damn good but you still have to go out of your way to work with it if you're not using its baby-tier box design.

There are safe / standard ways to use certain primitives. But then there's no guarantee that such algorithms will be made available in the libraries that you're trying to use. E.g. lets say you want to use RSA (for x509 certs or something like that.) You'll get access to RSA but no algorithm to handle padding and no mention of it. So the dev uses RSA as-is and then gets a lecture for padding.

Point is: I don't see many "cryptography experts" putting effort into improving developer documentation resources for libraries. But plenty of them ranting and acting butthurt that developers aren't educated enough to use the primitives. The same crypto experts will also release these libraries and then cry that people use them. Lol, lmao even?

soatok3• 1 year ago

I don't see many "cryptography experts" putting effort into improving developer documentation resources for libraries.

This isn't a "documentation resources for libraries" problem. It's a what libraries get bundled into the "crypto" module for your programming language problem, and that's largely a political decision rather than a technical one.

For example: Node's crypto module will always be a thin wrapper around OpenSSL, due to backwards compatibility. I cannot change that reality. There will always be a way to shoot yourself in the foot with Node.js's crypto module, and that is what most developers will reach for.

Even if I introduce new APIs for Node crypto and update the official docs to recommend the newer, safer ways of doing things, I won't be able to update the long tail of Stack Overflow answers with 10+ years of incumbency and hundreds of upvotes. This was tried years ago in the PHP community, and you still find bad PHP code everywhere.

Updating the developer documentation only serves to blame the poor user when they fuck up, so you can dismiss their pain with "RTFM".

But plenty of them ranting and acting butthurt that developers aren't educated enough to use the primitives. The same crypto experts will also release these libraries and then cry that people use them.

I have never contributed a line of code to OpenSSL. You do not hear Eric A Young "ranting and acting butthurt". What empirical evidence do you have for this assertion?

unscaled4• 1 year ago

Sure, even RSA can be used safely. This site's root certificate is still 4096-bit RSA, and that's probably OK (if we trust Let's Encrypt and our TLS implementations). If what your library exposed was a function called validate_x509_certificate_for_domain() that receives an X.509 certificate and a domain name and then validates it against your trusted root CAs then sure - you could write simple documentation on how to use it safely.

But if you want to use the general-purpose RSA functions, you're out of luck. The design of OpenSSL and Java's cryptography APIs is the stuff of nightmares, so let's take Go, which has a more modern RSA API[1]. Padding for encryption is not only mentioned, but mandatory (you either call rsa.EncryptPKCS1v15 or rsa.EncryptOAEP, you cannot use encrypt or decrypt RSA without padding if you really wanted to). The documentation would even nicely warn you not to use rsa.EncryptPKCS1v15 unless you need to maintain compatibility with a legacy protocol.

So can you just go ahead and use Go's "crypto/rsa" safely? No, of course not. RSA encryption (even with OAEP padding built-in) is such a low level operation that it would almost never be used alone. For instance, to encrypt a file with RSA, you will need to first encrypt an ephemeral random symmetric key, and then choose a symmetric algorithm and chaining mode. And in most cases, you also want to sign the envelope with your own public key.

So at the very least, if you want to build something like your own mini-PGP that is using legacy crap that can be somehow made safe just for the sake of sticking it to elitist cryptographers, you would need: A good RNG, RSA encryption (with OAEP), RSA signatures (with PSS), AES-CBC with PKCS#7 padding and SHA-256 (for the RSA signature). The documentation will have to mention all of that, and we still have only covered just a single use case: a toy mini-PGP. And let's not forget how to generate key. Go would always use e=65537, so we've got that covered, but you still need to know at least the recommended key size.

Unfortunately, unlike the baby-tier box design, our toy-tier mini-PGP doesn't have even perfect forward secrecy. So if we want to make it safe, and our requirements are to use prime number cryptography (because prime numbers are cool?) we'd have to add Diffie Hellman and that is it's own can of worms. But even with ecdh, we'd need to select a curve. Should the documentation should just tell the user to just select use ecdh.X25519, or should it go on explaining about Montgomery Ladder and Weierstrass scalar multiplication, invalid curve attacks and indistinguishability from uniform random strings[2]?

In the end of the day, we would end up with documentation the size of a couple of book chapters explaining how you could safely use a bunch of cryptographic primitives for one single thing (a toy mini-PGP). If we'd want to go further than that and explain how to safely implement something more complex, we'd end up with a couple of applied cryptography books. And if heavens forbid you'd want to implement a new protocol for secret messaging, we might have to include a few hundreds of research papers and perhaps a masters' degree program in cryptography.

And here we're back again to where we've been at the start. We've solved the issue by converting the random developer into an elitist cryptographer.

[1] https://pkg.go.dev/crypto/rsa#pkg-index

[2] https://safecurves.cr.yp.to/ind.html

archi42• 1 year ago

Ah, yes, common people and cryptography. I've recently been in a meeting with industrial people, the topic was securing industrial communication in production lines and such stuff: "Someone told us zero trust means we can establish secure communications between random devices without any root of trust". I think they plan to eventually standardize something around that. I'm looking forward to either be pleasantly surprised, or do a side quest to prevent them from making fools of themselves.

vaylian2• 1 year ago

To err is to be human, but to routinely make preventable mistakes because people with my exact skillset haven’t yet delivered easy-to-use, hard-to-misuse tooling in the programming languages actual developers use–meeting them where they are, as it were?

This paragraph shifts the blame around to the implentors of cryptographic libraries.

Some cryptographic assumptions can be enforced by a type system and runtime checks. But we probably still need to have good reading resources to learn about how to properly use common cryptographic algorithms so that developers can recognize when there is something awry with a cryptographic library. And these reading resources need to be well-known in the community to have an impact. Does anyone here know of some good books or good websites that explain the things that developers need to know?

some_furry12• 1 year ago

This paragraph shifts the blame around to the implentors of cryptographic libraries.

I think a subtlety here didn't scan for most HN users: I'm blaming myself when I write that.

Building the tools that solve your exact needs is my hobby horse. Providing developer tools that are easy to use and hard to misuse is a significant time investment of mine. For more on that, read any of my blog posts or GitHub repositories over the years.

It's extremely frustrating to me that, despite all of the effort I've put into this problem (both as my blogging persona and professionally), people still think "I'll try to encrypt secrets using Node's crypto module" in 2025, and end up with less secure implementations.

(If you want to go down this route of inventing it yourself, rather than using an off-the-shelf solution, start with hpke-js and forget RSA exists entirely.)

vaylian2• 1 year ago

I'm blaming myself when I write that.

The way I understand it: You are blaming yourself (and people in a similar position) because you know better and you have the ability to create better libraries.

But as someone who does a lot of software engineering, I also recognise that writing reliable software is time-intensive. And writing library code that doesn't have any cryptographic flaws is probably extra time-intensive, because there is no crypto-aware type checker or linter watching over your shoulder, because afaik these tools don't exist. Good cryptographic software is not written in a day and I know that this is very frustrating. I've got a lot of half-finished side-projects laying around...

But my original sub-point still stands: We need better well-known learning resources on how to use cryptographic algorithms correctly, so that we as developers can recognize misuse of/by libraries. And I'm happy to hear any suggestions for books and websites.

tpimenta2• 1 year ago

In the end the author expressed his frustration at the lack of input from security professionals, but the words he used were perhaps a little arrogant:

He said "to routinely make preventable mistakes because people with my exact skillset haven’t yet delivered easy-to-use, hard-to-misuse tooling".

I would suggest rephrasing this as a way to make it clear what skills he is referring to, something like "people who are senior security experts". Otherwise it might sound like he is implying that he is the only one who should audit everything, because who else would have the exact same experience that he has had all his life?

some_furry12• 1 year ago

I would suggest rephrasing this as a way to make it clear what skills he is referring to, something like "people who are senior security experts".

Well, it needs to say exactly what it says, not a vague category like "senior security experts".

There are countless developers and security nerds who run circles around me. They can do everything I can do, and more.

A lot of the trappings that cause developers to make preventable mistakes is because my betters and I haven't delivered easy-to-use tools that solve their use cases perfectly, and I feel personally responsible for not being able to help more.

Not sure what's arrogant about that.

tpimenta2• 1 year ago

Well, just thinking about the meaning of the word "exact" can be literal, the level of frustration suggests the emphasis is the highest, it can make the reader understand the meaning of "exact" is a literal irreducible exact, implying no one other than you have the literal exact same experience.

nonameiguess• 1 year ago

I'd argue there are easy-to-use tools for this use case, frankly. Buy your employees corporate Yubikeys, issue them over certified mail, and just use gpg in some authenticated mode. That may be too complicated for Grandma Marie and Uncle Paul, but is it seriously too complicated for someone trying to run a software business? How do you ever expect to understand the laws you have to comply with to run a business if that's your attitude?

If that's still too complicated, send each other API keys over Proton Mail. Unless you're an enemy of the Swiss government, I can't think of a reason not to trust them that isn't into serious crackpot territory. If you're actually being targeted by Mossad or the NSA, they can intercept your certified mail anyway. OpenAI would probably cooperate with them besides.

christophilus• 1 year ago

Aside: I appreciated this article and didn’t find it overly arrogant as others have suggested. It sounds like a security expert venting a bit after being exasperated. His gripes are legitimate, and his tone wasn’t out of line with the frustration I’d feel in the same situation. My 2cents.

heraldgeezer• 1 year ago

Cool furry banner

Hell is overconfident developers writing encryption code

Related Stories