11 ms·

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 t

• 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."
  • tptacek 2y 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.
    • pclmulqdq 2y ago
      Reasonable security engineers take a reasonable position on this. Many other developers (usually uninformed ones) believe this now means "don't make an auth system." Like it or not, this has become a sort of adage that people cargo-cult.
      • tptacek 2y ago
        If you can't keep the line between "ordinary developers shouldn't be working with AES" and "ordinary developers can write login systems" clear, you're doing people a disservice, because the two assertions are not alike in how fundamentally true they are.
        • pclmulqdq 2y ago
          By the way, I agree with you. My original point was that the "hivemind" somehow has shifted away from the reasonable conclusion.
• hoilmic 2y 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/ https://doc.libsodium.org/
  • unscaled 2y 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-answers/ https://www.latacora.com/blog/2018/04/03/cryptographic-right... [1] https://www.cryptofails.com/post/75204435608/write-crypto-code-dont-publish-it https://www.cryptofails.com/post/75204435608/write-crypto-co...
• deleted 2y ago
  [deleted]
• smolder 2y 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?
  • xvector 2y 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.
    • smolder 2y ago
      It wasn't 'an algorithms class' but grad level cryptography. We did implement boxes as a project and were graded on them. Where do you think people learn this stuff? Super secret cryptography school? I even used it. I previously built a secondary layer protocol using diffie hellman that runs on top of TLS such that in the event TLS is broken there's still some level of secrecy, and I'm very confident that it's better than nothing. Defense in depth, you know?
      • xvector 2y ago
        Yes, most of us have likely taken a grad level cryptography course. Still, that's not enough to securely roll your own crypto. You want many years of experience and a community of experts working with you. If you don't have that - 99.9999% of devs do not - just use libsodium.
        • smolder 2y ago
          The arrogance and elitism is wild. I never said people shouldn't use libsodium.
• Ekaros 2y 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...
• tptacek 2y 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.
  • hyperman1 2y 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.
    • tptacek 2y ago
      I ran the Cryptopals challenges. I have been sent AES implemented in 4 different assemblies, Julia before it was launched, pure Excel spreadsheet formulae, and a Postscript file.
      • hyperman1 2y ago
        There must be beauties in there;-). Even so, the fact that it's called Cryptopals indicates a public having some basic level of care about crypto. The non-it person hacking an excel macro together to get some job done has a very different attitude, and they do run their stuff in production.
• ozim 2y 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.
• z3t4 2y 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.
  • smitelli 2y 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 2y 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?
    • BenjiWiebe 2y ago
      Add to encrypt, so 32 is always Z.
    • z3t4 2y ago
      It's unbreakable, google for "one time pad" encryption. The problem with cracking it is that if you just change one letter in an English word it becomes another English word. Here i have encrypted "hackernews" with the following key 2,3,1,6,2,1,2,2,1,3 Good luck cracking it without the key: JDDQGSPGXV
      • loup-vaillant 2y ago
        As was said above, don't just add a number from 1 to 6. You want your ciphertext to be indistinguishable from random, so in this case (assuming only letters and no punctuation nor space), you need to add a number from 0 to 26. And you need a uniform distribution, or again, statistical analysis will screw you. Now one does not simply generate a uniform random distribution from a d6. You can't throw the die 5 times and add the results for instance. First, you'll get a number between 5 and 30. Not only the range falls short one letter (25 possibilities instead of 26), what you get is a binomial distribution, heavily skewed towards the middle numbers (5 and 30 are very improbable in comparison). My recommendation here would be to throw the die once, subtract 1, multiply by 6, throw it a second time, add it, subtract 1. This will give you a uniform distribution between 0 and 35 (assuming your die is perfectly fair, which, spoiler alert, it isn't). Think of it of a 2-digit base 6 number. Assign a number to each letter of the alphabet (and now you can even support spaces & punctuations, or numbers), add (modulo 35) the result of your die throw, do not translate the result to an encoding with less than 36 symbols, and now you have a proper one time pad. One thing that's crucial when attempting anything cryptographic: make sure you've got the maths down. Ideally you should be able to construct a rigorous (even machine verified) proof that your stuff works as intended. For the one time pad it's relatively easy. But you need to do it, that's how you'll notice that if you encrypt "aaaaaaaaa" your result will only yield letters between B and G, which you'll agree doesn't hide your plaintext nearly as well as you intended.
• philjohn 2y 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.
• deleted 2y ago
  [deleted]
• nazgul17 2y 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.