10 ms·

Hell is overconfident developers writing encryption code

201 points by zdw 2y ago

Andy101 2y ago
[dead]
Aeolun 2y 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.
- tptacek 2y ago
  I don't love the post either but getting angry about it doesn't make it less right.
  - Aeolun 2y 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 2y 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.
- deleted 2y ago
  [deleted]
- YZF 2y 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.
  - Aeolun 2y 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 2y 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.
- Uptrenda 2y 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 2y 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 2y 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.
deleted 2y ago
[deleted]
tptacek 2y 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 2y 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?
  - tptacek 2y 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."
    - pclmulqdq 2y ago
      I have become a bit of a cryptographer (after running a cryptography-related company for a while), and aside from joke thought experiments, I am one of the most conservative cryptographic programmers I know. I'm personally pretty skeptical that the first round of PQC algorithms have no classically-exploitable holes, and I have seen no evidence as of yet that anyone is close to developing a computer of any kind (quantum or classical) capable of breaking 16k RSA or ECC on P-521. The problem I personally have is that the lattice-based algorithms are a hair too mathematically clever for my taste. The standard line is around store-now-decrypt-later, though, and I think it's a legitimate one if you have information that will need to be secret in 10-20 years. People rarely have that kind of information, though.
jasonjayr 2y 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.
- jiggawatts 2y 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 2y ago
    The was at least also TLS on top of that, yes?
Sytten 2y 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_furry 2y 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.
  - Sytten 2y 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.
    - some_furry 2y ago
      The problem isn't "the server sends me a public key". The problem is there's no way to know if the server is lying.
voxelc4L 2y ago
… or any code?
devmor 2y 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 2y ago
The insecurity is freedom. Think of that again when you need to break out of Big Tech's control.
- tptacek 2y ago
  What? Say more.
  - saurik 2y 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 https://youtu.be/WyBgn06LNOY
    - tptacek 2y ago
      I mean, that I get? I'm a professional connoisseur of cryptography vulnerabilities, so, for completely different reasons, I'm also happy to see things blow up. But like, the general sentiment of "it would be best if any given cryptosystem blew up", that sentiment I do not get. Platform security modules, sure (though: at that point you're conceding a lot to governments).
Dibby053 2y 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 https://github.com/gristlabs/secrets.js/issues/2
- rendaw 2y ago
  And the critic's only argument is a link to their own blog...
- hatf0 2y 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 https://github.com/getsops/sops), or age (made by the fantastic Filo Sottile: https://github.com/FiloSottile/age https://github.com/FiloSottile/age), or, hell, just using libsodium sealed boxes. AMS KMS or Vault is perhaps even worse of an answer, Actually
- maqp 2y 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.
  - LPisGood 2y 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?
jhack 2y ago
Don't forget to rand(rand()).
TheCleric 2y 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.
- throwaway984393 2y ago
  [dead]
- maqp 2y 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 2y 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 2y 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 2y 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 2y 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-01 2y 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.
- AlotOfReading 2y 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 2y 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.
  - borski 2y ago
    That’s what the actual crypto classes are for. If people are intrigued, those are fantastic elective courses.
tombert 2y ago
Nah, hell is being stuck writing Kubernetes configs.
quotemstr 2y 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.
umvi 2y 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?
- LPisGood 2y ago
  Cryptographic protocols are algorithms built on cryptographic primitives and they have plenty of footguns.
- EE84M3i 2y 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.
  - deleted 2y ago
    [deleted]
  - magicalhippo 2y 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 https://www.rfc-editor.org/rfc/rfc5869
- pclmulqdq 2y 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."
foobarkey 2y 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
- AlotOfReading 2y 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 2y 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?
- erinaceousjones 2y 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!
  - maqp 2y ago
    >so I do wonder if it's missing any new state of the art / best practises. https://nostarch.com/serious-cryptography-2nd-edition 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 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_ 2y 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.
- tptacek 2y 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.
  - AlotOfReading 2y 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.
    - xvector 2y ago
      If you're having to constantly remind your security engineers about "degrees of security," they may be trying to tell you that your threat model is unsustainably/nonsensically/dangerously lax.
      - AlotOfReading 2y ago
        The part I've been struggling with is getting them to put any threat model in writing that's not quote, "everything".
markus_zhang 2y 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 2y ago
Just add 2 to each char.
sureglymop 2y 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.
- Ekaros 2y 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.
  - sureglymop 2y 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.
    - chupasaurus 2y ago
      > I get that. But then, keeping that legacy stuff running is just as problematic as rolling your own crypto. Both problems are from the lack of knowledge, but latter one is orders of magnitude harder to fix.
    - maqp 2y ago
      >We can leave OpenSSL as it is but it shouldn't be the popular recommendation for developers. OpenSSL isn't a recommendation for developers. For TLS, LibreSSL and BoringSSL are. For other stuff, libsodium is. The only reason I've picked OpenSSL, is it has a higher level library (pyca/cryptography) that gives bindings to X448.
- izacus 2y ago
ExoticPearTree 2y 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.
ethin 2y 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 https://github.com/ethindp/noise-cpp
- AgentME 2y 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.
  - ethin 2y 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.
    - some_furry 2y ago
      > I just take issue with it being something you'd apply to all crypto code. That this discussion is happening at all in response to a blog post that begins by linking to https://www.cryptofails.com/post/75204435608/write-crypto-code-dont-publish-it https://www.cryptofails.com/post/75204435608/write-crypto-co... is amusing and concerning in equal measure. I don't care if you write crypto code. I never said I cared if you write crypto code. But don't: 1. Deploy your code 2. Publish your code in a package ecosystem 3. Encourage other people to use your code ...unless it's survived the gauntlet of peer review and has a good rationale for existing in the first place. The reason I proposed an onion model for this discourse is that there isn't a binary switch where "if you do X you are rolling your own crypto but if you do Y you aren't rolling your own crypto". The deeper you slice, the more danger and responsibility you've incurred. People who think "it's fine to build a custom protocol out of cryptography bricks because I'm not rolling my own bricks" are the highest risk group in software developers. Even moreso because (as tptacek constantly points out) most vulnerabilities occur at the joinery.
Uptrenda 2y 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?
- soatok 2y 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?
archi42 2y 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.
vaylian 2y 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_furry 2y 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.)
  - vaylian 2y 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.
tpimenta 2y 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_furry 2y 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.
  - tpimenta 2y 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 2y 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.
deleted 2y ago
[deleted]
christophilus 2y 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 2y ago
Cool furry banner
kevinprice 2y ago
[dead]
deleted 2y ago
[deleted]
angiolettawood 2y ago
[dead]

201 points by zdw 2y ago

[dead]

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.

tptacek 2y ago
I don't love the post either but getting angry about it doesn't make it less right.
- Aeolun 2y 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 2y 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.
deleted 2y ago
[deleted]
YZF 2y 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.
- Aeolun 2y 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 2y 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.
Uptrenda 2y 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 2y 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 2y 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.

deleted 2y ago

[deleted]

tptacek 2y 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 2y 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?
- tptacek 2y 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."
  - pclmulqdq 2y ago
    I have become a bit of a cryptographer (after running a cryptography-related company for a while), and aside from joke thought experiments, I am one of the most conservative cryptographic programmers I know. I'm personally pretty skeptical that the first round of PQC algorithms have no classically-exploitable holes, and I have seen no evidence as of yet that anyone is close to developing a computer of any kind (quantum or classical) capable of breaking 16k RSA or ECC on P-521. The problem I personally have is that the lattice-based algorithms are a hair too mathematically clever for my taste. The standard line is around store-now-decrypt-later, though, and I think it's a legitimate one if you have information that will need to be secret in 10-20 years. People rarely have that kind of information, though.

jasonjayr 2y 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.

jiggawatts 2y 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 2y ago
  The was at least also TLS on top of that, yes?

Sytten 2y 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_furry 2y 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.
- Sytten 2y 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.
  - some_furry 2y ago
    The problem isn't "the server sends me a public key". The problem is there's no way to know if the server is lying.

voxelc4L 2y ago

… or any code?

devmor 2y 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 2y ago

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

tptacek 2y ago
What? Say more.
- saurik 2y 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 https://youtu.be/WyBgn06LNOY
  - tptacek 2y ago
    I mean, that I get? I'm a professional connoisseur of cryptography vulnerabilities, so, for completely different reasons, I'm also happy to see things blow up. But like, the general sentiment of "it would be best if any given cryptosystem blew up", that sentiment I do not get. Platform security modules, sure (though: at that point you're conceding a lot to governments).

Dibby053 2y 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 https://github.com/gristlabs/secrets.js/issues/2

rendaw 2y ago
And the critic's only argument is a link to their own blog...
hatf0 2y 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 https://github.com/getsops/sops), or age (made by the fantastic Filo Sottile: https://github.com/FiloSottile/age https://github.com/FiloSottile/age), or, hell, just using libsodium sealed boxes. AMS KMS or Vault is perhaps even worse of an answer, Actually
maqp 2y 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.
- LPisGood 2y 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?

jhack 2y ago

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

TheCleric 2y 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.

throwaway984393 2y ago
[dead]
maqp 2y 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 2y 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 2y 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 2y 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 2y 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-01 2y 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.

AlotOfReading 2y 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 2y 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.
- borski 2y ago
  That’s what the actual crypto classes are for. If people are intrigued, those are fantastic elective courses.

tombert 2y ago

Nah, hell is being stuck writing Kubernetes configs.

quotemstr 2y 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.

umvi 2y 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?

LPisGood 2y ago
Cryptographic protocols are algorithms built on cryptographic primitives and they have plenty of footguns.
EE84M3i 2y 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.
- deleted 2y ago
  [deleted]
- magicalhippo 2y 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 https://www.rfc-editor.org/rfc/rfc5869
pclmulqdq 2y 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."

foobarkey 2y 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

AlotOfReading 2y 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 2y 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?

erinaceousjones 2y 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!
- maqp 2y ago
  >so I do wonder if it's missing any new state of the art / best practises. https://nostarch.com/serious-cryptography-2nd-edition 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 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_ 2y 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.

tptacek 2y 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.
- AlotOfReading 2y 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.
  - xvector 2y ago
    If you're having to constantly remind your security engineers about "degrees of security," they may be trying to tell you that your threat model is unsustainably/nonsensically/dangerously lax.
    - AlotOfReading 2y ago
      The part I've been struggling with is getting them to put any threat model in writing that's not quote, "everything".

markus_zhang 2y 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 2y ago

Just add 2 to each char.

sureglymop 2y 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.

Ekaros 2y 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.
- sureglymop 2y 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.
  - chupasaurus 2y ago
    > I get that. But then, keeping that legacy stuff running is just as problematic as rolling your own crypto. Both problems are from the lack of knowledge, but latter one is orders of magnitude harder to fix.
  - maqp 2y ago
    >We can leave OpenSSL as it is but it shouldn't be the popular recommendation for developers. OpenSSL isn't a recommendation for developers. For TLS, LibreSSL and BoringSSL are. For other stuff, libsodium is. The only reason I've picked OpenSSL, is it has a higher level library (pyca/cryptography) that gives bindings to X448.
izacus 2y ago

ExoticPearTree 2y 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.

ethin 2y 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 https://github.com/ethindp/noise-cpp

AgentME 2y 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.
- ethin 2y 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.
  - some_furry 2y ago
    > I just take issue with it being something you'd apply to all crypto code. That this discussion is happening at all in response to a blog post that begins by linking to https://www.cryptofails.com/post/75204435608/write-crypto-code-dont-publish-it https://www.cryptofails.com/post/75204435608/write-crypto-co... is amusing and concerning in equal measure. I don't care if you write crypto code. I never said I cared if you write crypto code. But don't: 1. Deploy your code 2. Publish your code in a package ecosystem 3. Encourage other people to use your code ...unless it's survived the gauntlet of peer review and has a good rationale for existing in the first place. The reason I proposed an onion model for this discourse is that there isn't a binary switch where "if you do X you are rolling your own crypto but if you do Y you aren't rolling your own crypto". The deeper you slice, the more danger and responsibility you've incurred. People who think "it's fine to build a custom protocol out of cryptography bricks because I'm not rolling my own bricks" are the highest risk group in software developers. Even moreso because (as tptacek constantly points out) most vulnerabilities occur at the joinery.

Uptrenda 2y 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?

soatok 2y 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?

archi42 2y 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.

vaylian 2y 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_furry 2y 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.)
- vaylian 2y 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.

tpimenta 2y 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_furry 2y 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.
- tpimenta 2y 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 2y 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.

deleted 2y ago

[deleted]

christophilus 2y 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 2y ago

Cool furry banner

kevinprice 2y ago

[dead]

deleted 2y ago

[deleted]

angiolettawood 2y ago

[dead]