14 ms·

The Cryptographic Doom Principle

142 points by lobo_tuerto 12y ago

mnw21cam 12y ago
I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.
- madez 12y ago
  This is a common idea and it's flawed. Let KC be a well-known and implemented cipher and CC a custom cipher written by you. Instead of communicating like this: A -> KC-encrypt -> transport -> KC-decrypt -> B You can use: A -> KC-encrypt -> CC-encrypt -> transport -> CC-decrypt -> KC-decrpyt -> B The advantage is it breaks automated cryptoanalysis in case KC is broken. A better idea than the one you stated is: don't rely solely on custom cryptography.
  - jxcl 12y ago
    That makes sense intuitively, but you can't approach cryptography intuitively. There are many cases where the intuitive answer is "well, the worst case is that it's just as good as without our custom wrapper... so let's do it." But under cryptographic analysis it is revealed that the custom wrapper renders whatever other good, accepted cryptography that is in play completely useless.
    - madez 12y ago
      Rendering KC useless by using CC as I described is equivalent to breaking KC. There is no other way of messing with KC when used the way I said. And you won't break KC by chance with your CC. Many people respond like you did and they simply didn't think about what I've said and repeat old ideas. I hate people.
      - sirclueless 12y ago
        This is not a true statement. CC may leak information about the plaintext in ways that KC can't handle, even without breaking it. For example, applying CC might deterministically affect the message length. One of my favorite cryptographic attacks ever was of this form, known as the CRIME attack [1]. It was a "partial plaintext" attack, where the "CC" in question was plain old gzip. Basically the attackers controlled a small part of the plaintext (for example, a field in an HTTPS request they could send with CSRF) and they were able to use known properties of the CC to get some information to leak into the message length -- namely, if the message fragment they controlled appeared elsewhere in the request, the gzip encoding would be shorter, and hence the encrypted request would be shorter. This is something that happens even with a "perfect" KC that no one could break. [1]: http://en.wikipedia.org/wiki/CRIME http://en.wikipedia.org/wiki/CRIME This is one of the defining characteristics of cryptography to me -- there are no perfect cyphers, there are only good systems. Littering extra cryptography around nearly always decreases security. The most secure system is the simplest system that works.
        madez 12y ago
        Read this thread again. Your statement is not correct since CC never gets to see the plaintext. CC is just a bijective function on (blocksize of KC) bits.
        sirclueless 12y ago
        Did you edit your post? I'm not the only one who misread it. If KC is applied first to the plaintext, then assuming you didn't flub anything in implementation the combined scheme won't be less secure than KC, I agree. Applying CC effectively becomes security through obscurity, which is admittedly sometimes helpful.
        madez 12y ago
        No, sirclueless, I didn't change the scheme I wrote about. Yes, it adds security through obscurity without losing security through well-known recommended ciphers.
    - dustyleary 12y ago
      I need to see a citation for this. Something like the parent article exposing how things get mistakenly broken by applying this concept. It's important to be paranoid about implementing your own crypto, true. But it's not good to take this to dogmatic extremes, ie "never trust any code you write that has crypto in the name or you break everything". I would never write and deploy a custom cypher. But if I did, and my custom cipher CC, when applied to ciphertext encrypted by AES, somehow leaked any information about the plaintext, then I have accidentally made a cryptanalysis breakthrough that has thwarted hundreds of professional crypto people. This is unlikely.
      - deleted 12y ago
        [deleted]
      - deleted 12y ago
        [deleted]
      - stouset 12y ago
        In madez's case, his construct is provably secure, with some caveats. Specifically, the first cipher must be a secure cipher, and the keys for both ciphers must be independent. If the latter is not the case, the custom cipher could very easily leak bits of the key, which would allow the original cipher to be broken. But more importantly, it's the implementation of this construct that's likely to introduce weaknesses. As I posted in my direct reply to him, the problem is that no real world protocol is so simple, and he will now have to implement this. See OpenSSL for what can go wrong when implementing ciphers; and that's a highly-used, generally stable project that's had the benefit of multiple eyeballs for years.
        rudolf0 12y ago
        Exactly. And if the first cipher is a secure cipher, with no obvious sign it'll be broken any time soon (like AES), why not just use it instead of wrapping it over some homebrew solution?
        madez 12y ago
  - kelson 12y ago
    This is almost always less secure than KC alone, when KC is a well-known secure cipher. A simple example would be a CC that hex-encodes the plaintext before applying some transformation on the data (before you laugh, this exists in enterprise systems today). This means CC would effectively expand the underlying data 200% (0xA1 -> 0x4131) and substantially degrade the security of a block-based cipher (32-bit block -> effectively 16-bits). Here's a link to a practical case of unsafe composition (in hashing): http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html http://blog.ircmaxell.com/2015/03/security-issue-combining-b... A bit more detail on randomly composing encryption algorithms: http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html http://blog.cryptographyengineering.com/2012/02/multiple-enc... edit: It would be better to compose CC(KC(P)) so CC can't leak any information about P or degrade KC. Any reluctance to show the world the output of CC should suggest the low-practical-value of CC.
    - madez 12y ago
      CC doesn't get to see the plaintext in the construct I explained. CC is just a bijective function on (blocksize of KC) bits. The author of the mentioned blog ignores the fact that cascading ciphers like I described breaks automated cryptoanalysis which is a necessity for mass surveillance in a world with wide-spread cryptography.
      - sarciszewski 12y ago
        Cascade Ciphers were out of scope. Moxie was addressing the order of operations for authentication and encryption.
      - kelson 12y ago
        You're right; I misread your construct as KC(CC(P)). Your construct [CC(KC(P))] shouldn't be weaker than KC, unless information or resources are shared by CC and KC (such as keys). Shared information or resources may introduce side channel attacks. Per the previous link, this is likely only practicable on entirely separate machines. Any entity that can break AES at-scale will undoubtedly find any unreviewed cryptographic protocol trivial to break. Any such at-scale effort would already include attacks against typical bad-custom-crypto (because they're extremely easy and common), in addition to the AES attacks. Cascading ciphers, particularly weak ones, will not stop the NSA. edit: addressed information leak if CC & KC share keys/resources
  - stouset 12y ago
    Technically, you're correct. In the real world, you're not. This mythical protocol just encrypts a blob and sends it over the wire. But real protocols involving cryptography are significantly more complicated, because they often need to authenticate other parties, cryptographically bind all the messages in a session, preserve forward secrecy, preserve anonymity of one of the communicating parties, etc. Now the problem isn't that you are simply applying your own cipher to the output of a strong cipher. It's that you've now got to implement a damn protocol, because nothing in the world supports your cipher. And that implementation is inevitably going to have more exploitable flaws than a well-maintained open-source project that doesn't implement your bogocipher. Cryptography is hard, and it's not just the primitives that are ripe for gotchas. Combining primitives, implementing primitives, designing protocols, implementing protocols, and generally anything involving touching something anywhere in the entire stack is fraught with danger. As a rule, the more crypto-related lines of code you write, the more likely it is you have introduced weaknesses rather than added strength.
    - madez 12y ago
      Technically correct is the best way of correct. I never suggested my proposal for public protocols for communication between two random parties. I first and all wanted to show the root of this thread wrong. I'd suggest it maybe for highly confidential communication that warrants the trouble.
      - stouset 12y ago
        Technically correct is usually the least useful kind of correct. The root of this thread is extremely sound advice. Don't touch your own crypto unless you're an expert. If you're at the point where your security requirements are so sensitive that you can't possibly risk a break in an underlying well-known cipher, you should hire a real cryptographer and not dick around with inventing your own laughably-broken ciphers. And once you have that cryptographer under your employ, you can feel free to break the rule of not rolling your own crypto. Although that cryptographer is infinitely more likely to simply compose well-known strong ciphers over deploying their own unpublished ones.
  - Strilanc 12y ago
    Most of the responses seem to be talking about A -> Custom -Strong -> Unstrong -> Uncustom instead of A -> Strong -> Custom -> Uncustom -> Unstrong*. Some potential problems with applying a custom transform to the cyphertext: - The custom transform might have effects on cache that create opportunities for timing attacks - The custom transform might have a buffer-overflow (just like any other excess code) - The custom transform might support features exploitable in DOS attacks, like run-length encoding - The custom transform might be slow, costing time and money - Sometimes applying two transforms is equivalent to encrypting with a different key (e.g. DES has this property). Might create meet-in-the-middle attacks. - If the custom transform is given the same key as the strong crypto, as a lazy programmer might do, it could leak the key - Switching the ordering of the transforms is a deadly mistake, but easy to glance over - If the strong transform starts with an HMAC, as it should, that can be used to break the custom transform's key anyways (see the post we're commenting on) Mostly those are small things. But the security benefit you get is also small.
    - madez 12y ago
      > Most of the responses seem to be talking about A -> Custom -Strong -> Unstrong -> Uncustom instead of A -> Strong -> Custom -> Uncustom -> Unstrong*. Yes :( > Some potential problems with applying a custom transform to the cyphertext: > - The custom transform might have effects on cache that create opportunities for timing attacks > - The custom transform might have a buffer-overflow (just like any other excess code) This are for the point of my comment irrelevant implementation details. You could apply the custom transform on another computer. > - The custom transform might support features exploitable in DOS attacks, like run-length encoding The custom transform ought to be a bijective function on (blocksize of Strong) bits. > - The custom transform might be slow, costing time and money It was never meant as a suggestion for wide-spread usage. > - Sometimes applying two transforms is equivalent to encrypting with a different key (e.g. DES has this property). Might create meet-in-the-middle attacks. > - If the custom transform is given the same key as the strong crypto, as a lazy programmer might do, it could leak the key The custom transform shouldn't know at all about anything of the strong cipher. Another implementation detail. > - Switching the ordering of the transforms is a deadly mistake, but easy to glance over Another implementation detail. > - If the strong transform starts with an HMAC, as it should, that can be used to break the custom transform's key anyways (see the post we're commenting on) I just wanted to show the common idea of "cryptography is black magic, you should never touch it, you can only do bad things" wrong. My scheme adds security through obscurity which may be worth the trouble.
  - angry_octet 12y ago
    So wrong. Your custom cipher could be leaking key material in the encrypted output, almost certainly leaks the key via timing channels, could be leaking the known cipher key by timing channels and more (and this is assuming separate keys). The CC decode stage will be subjected to every possible edge case to see if it will do something dumb, like the oracle attacks mentioned in the article. And it could also leak information about the KC decode via timing attacks. If this was for offline file encryption, where you do the steps separately, maybe okay. But not for online encryption where chosen plaintext is possible.
    - madez 12y ago
      Read this thread. CC is a bijective function on (blocksize of KC) bits. CC knows nothing at all about KC. Implementation can be done in another computer without security problem while you get obscurity. Read this thread.
      - angry_octet 12y ago
        You don't mention separate computers until now. It's a big difference. I thought we were discussing implementing crypto, not some theoretical properties you achieve when conditions are just right. I'm not saying trust the Windows implementation of AES, you can put it through some other cipher with a strong implementation as well, but don't just make up your own one.
- sarciszewski 12y ago
  > Use a pre-existing cryptography package that has been written properly instead. Okay, name one that has been written properly that the average web developer is going to encounter. I'm going to focus on PHP because that's what I know best, it has an enormous market share, and I'm not a fan of blowing smoke (which I would be if I tried to speak to, e.g. Perl development). PGP? OTR? Axolotl? These aren't part of your standard dev environment. Mcrypt? Hasn't been touched since 2007. There is at least a patch for a bug in the 64-bit implementation of CAST-256 that has been sitting, unmerged, for six years. Libsodium is the best we have, and you need PECL access to install it. OpenSSL is labyrinthine. http://stackoverflow.com/a/29331937/2224584 http://stackoverflow.com/a/29331937/2224584 It's still messy, despite the past year of attention from the security industry, but it's getting better. This library offloads its underlying cryptography to OpenSSL because it's the best we got: https://github.com/defuse/php-encryption/ https://github.com/defuse/php-encryption/ Maybe Python, Ruby, and Node developers have better options available to them. But 83% of the Internet runs PHP, and having a properly written cryptography package just isn't a trivial bar to leap over.
  - corndoge 12y ago
    Considering that the original comment never specified web developers, you seem to be responding to an argument that wasn't made.
    - anon4 12y ago
      His point does bear consideration - the expert-written libraries are only expert-usable. You can still badly mess up encryption even if your basic building blocks are written perfectly. It's not just the algorithms that need to be expertly written, it's the way they're combined that also needs to be expertly written and the latter part doesn't exist. OpenSSL allows you to shoot yourself in the foot pretty easily, like choosing very weak ciphers, calculating the mac of the plaintext, etc. OpenSSL is still too low-level for the generic developer. You want things like HTTPS, using which is still too complicated for most people (hello certificate management), but you can get it right more easily by following an online tutorial. Basically anything that is more complicated than "open socket to destination, here's my certificate" is doomed to be misused by non-experts. Oh, and it better have strong default settings so it won't pick RC4 as the cipher or something.
- TorKlingberg 12y ago
  This article is clearly written for the experts who are implementing cryptography.
  - billyhoffman 12y ago
    On its face I guess it is. But really, this is just another demonstration of maxim "Don't do work for untrusted parties". Yes, this applies to cryptography, but also to network protocol design, and even software design in general. Recursive DNS lookup DoS attacks? You are doing work for some you don't know (random UDP packets) The recent NTP DDoS amplification issues? Doing work for someone you don't know (Again. unauth-ed UDP packet trigging craploads of work) Padded Oracle attacks in Crypto? Doing work for someone you don't know, and leaking data based on when something fails. IP Source routing? Doing work for an untrusted party! The moral of this story is verify what you have before you work on it. It all comes down to validating user input and user source.
- bradleyjg 12y ago
  That's good advice, and I've given it myself, but that doesn't mean you shouldn't read and play around with cryptography if it interests you. I implemented a simplified version of the referenced Vaudenay attack as part of Dan Boneh's Cryptography I course on courseara+. The course was very interesting, and also fun. I'm not ready to go out and implement my own cryptography, but knowing a bit about the subject makes me a more intelligent consumer of crypto libraries. While warning people away from implementing their own cryptography we have to make sure we don't scare people off from the subject altogether. After all, absolute top experts have to start somewhere. + https://www.coursera.org/course/crypto https://www.coursera.org/course/crypto
  - classicsnoot 12y ago
    Thank you for the link and the review. I start my CS degree in the Fall; i hope i can start and finish this before then.
    - pmalynin 12y ago
      For the love of all that is sacred, take advanced math and linear algebra.
      - rcthompson 12y ago
        I heartily agree with this sentiment. I have a friend who's a few years older than I am. He majored in CS, and told me in retrospect that he wished he had majored in mathematics instead. I took his advice, and, instead of doing CS major + a few math classes, I did math major + a few CS clases. I am now very glad that I did so. (For context, my friend and I are both data analysts now.)
        pmalynin 12y ago
        My comment comes from experience of being in progress of doing an Honors CS - Honors Math double major. After having completed Honors Calculus I/ II, Honors Linear Algebra Imy /II circuits in my first year I felt about 2-3 years ahead in my knowledge of mathematics and associated rigor -- this was especially evident when I was taking combined CS/EE courses and seeing student struggle with concepts that I thought were basic (infinimums, supremums, etc.) but apparently are not covered over the course of 2 years in the regular streams.
- bachback 12y ago
  what kind of "experts"? like NIST experts or experts at Microsoft? this a non-sensical meme in cryptography. it all comes down to the value at risk. at some price point you can hire people i.e. invest the resources to get it right. the reality is that many security libraries and principles are ancient and infrequently updated, that much of the research in the field is academic and useless. I think its much better to think in terms of risks. good security usually doesn't more value than bad security, until there is a breach.
  - angry_octet 12y ago
    Yeah, you got it, the people at NIST and M$ are going to do better than you. 'Academic and useless' research huh? Go read DJB's website some day, it is far from inapplicable. All the research that publicly disclosed HUGE holes in SSL? I think it's incredibly important. As to good security being of little value, maybe ask Sony and Adobe (and even NSA) if they wished they had better security.
- bitL 12y ago
  Even experts can go terribly wrong; there are known embarrassing attacks that invalidated algorithms considered rock-solid for 10 years by some bright 15-year old students. Would you prevent those brights from tackling on better ways to do crypto because they aren't "top experts" yet? Most likely they will just run away in disgust and park their capabilities in less hostile field. Celebritism doesn't really work in science; it only prevents progress.
  - 3am 12y ago
    1) Experts in all fields are always wrong sometimes. The nonexperts are wrong more frequently on average and people are less interested in proving them wrong. 2) Saying that implementing your own cryptography usually implies a production environment. I think it's generally assumed that nobody cares what people do with their own time/personal projects. 3) Trite sounds bites don't work in science either, and expert -/-> celebrity.
    - bitL 12y ago
      Ad 2) most groundbreaking projects you know originated as messy ad-hoc personal projects and not in production-sanitized environments (look even at GPG, embarrassingly for crypto community with one almost bankrupt developer). Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down and point to obvious flaws that can be fixed in minutes by someone experienced, while keeping the new idea intact. The crypto requires such an enormous amount of talent that it is bright individuals, not companies, that make things move there, and quite often the more people involved, the worse results.
      - deleted 12y ago
        [deleted]
      - stouset 12y ago
        > someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down I'm sorry, but this is essentially never the case. This is no different than in other fields, for instance math or physics, where complete novices come in every day believing they've had a completely novel idea that will revolutionize the field. 999,999 times out of a million they haven't, and in the one remaining case they've come up with a solution in search of a problem. "Oh, you've come up with a new cipher? Congratulations. Assuming it is secure, why should we use it ? Is it faster than existing ones? Simpler and more likely to be implemented correctly? Resistant to timing attacks? Resistant to CPU power analysis? Resistant to differential cryptanalysis? Suitable for low-CPU and low-memory embedded devices? Oh, none of these things? Gee, how interesting." I'm reminded of http://www.scottaaronson.com/blog/?p=304 http://www.scottaaronson.com/blog/?p=304
- chm 12y ago
  What constitutes a "top expert"? I'd want the people writing cryptography software to have made mistakes and learned from them. That's how the software gets better, no? Of course, there's a theoretical minimum to be familiar with.
kkl 12y ago
The "Don't roll your own crypto" mantra is overly ambiguous and enforces the culture of elitism in information security. I hope that something displaces this regurgitated "advice" with something more helpful. I know Moxie's article is a few years old but it is a step in the right direction regardless. --EDIT-- I don't think I was perfectly clear in my original comment. I attempted to expand on my position in a follow-up comment: https://news.ycombinator.com/edit?id=9376131 https://news.ycombinator.com/edit?id=9376131
- madez 12y ago
  This. The problem is that in this community you are witch-hunted if you talk about crypto and you are not a famous cryptographer. People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem).
  - daeken 12y ago
    > People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem). I've been dealing with crypto on a near-daily basis for the last 15 years. I'm well within the top percentile of understanding of the subject, from a theoretical and practical standpoint, having worked to break cryptographic protocols for most of my life. I wouldn't trust myself to design a crypto protocol for grocery lists, let alone anything important. This isn't false modesty or elitism or ignorance. It's recognizing that even if every smart person I know looks at it and says it's fine, it probably isn't. Crypto isn't hard to get right -- that's actually not the argument that anyone will make -- but it's impossible to know if you did get it right or not. You do not have the knowledge required to build safe cryptographic protocols. Neither does anyone else on this site.
    - madez 12y ago
richo 12y ago
If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.
- sas 12y ago
  it's like Pascal's Wager for security
- deleted 12y ago
  [deleted]
  - deleted 12y ago
    [deleted]
- kkl 12y ago
  I do not have concerns with the mantra itself just it's usage and the entitlement that often comes along with using it. The top answer on this Stack Exchange question is a good example of what I believe to be proper usage of the mantra. http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own http://security.stackexchange.com/questions/18197/why-should...
- a1a 12y ago
  Schneier's Law comes to mind "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." https://www.schneier.com/blog/archives/2011/04/schneiers_law.html https://www.schneier.com/blog/archives/2011/04/schneiers_law...
  - kleer001 12y ago
    Oh, that's what that is! I had found a similar thing making my own puzzles, "It's easy to make a puzzle you can't solve, but it's hard to make a puzzle that's fun." Well, that' not entirely the same thing, but they overlap I guess.
  - derefr 12y ago

142 points by lobo_tuerto 12y ago

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

madez 12y ago
This is a common idea and it's flawed. Let KC be a well-known and implemented cipher and CC a custom cipher written by you. Instead of communicating like this: A -> KC-encrypt -> transport -> KC-decrypt -> B You can use: A -> KC-encrypt -> CC-encrypt -> transport -> CC-decrypt -> KC-decrpyt -> B The advantage is it breaks automated cryptoanalysis in case KC is broken. A better idea than the one you stated is: don't rely solely on custom cryptography.
- jxcl 12y ago
  That makes sense intuitively, but you can't approach cryptography intuitively. There are many cases where the intuitive answer is "well, the worst case is that it's just as good as without our custom wrapper... so let's do it." But under cryptographic analysis it is revealed that the custom wrapper renders whatever other good, accepted cryptography that is in play completely useless.
  - madez 12y ago
    Rendering KC useless by using CC as I described is equivalent to breaking KC. There is no other way of messing with KC when used the way I said. And you won't break KC by chance with your CC. Many people respond like you did and they simply didn't think about what I've said and repeat old ideas. I hate people.
    - sirclueless 12y ago
      This is not a true statement. CC may leak information about the plaintext in ways that KC can't handle, even without breaking it. For example, applying CC might deterministically affect the message length. One of my favorite cryptographic attacks ever was of this form, known as the CRIME attack [1]. It was a "partial plaintext" attack, where the "CC" in question was plain old gzip. Basically the attackers controlled a small part of the plaintext (for example, a field in an HTTPS request they could send with CSRF) and they were able to use known properties of the CC to get some information to leak into the message length -- namely, if the message fragment they controlled appeared elsewhere in the request, the gzip encoding would be shorter, and hence the encrypted request would be shorter. This is something that happens even with a "perfect" KC that no one could break. [1]: http://en.wikipedia.org/wiki/CRIME http://en.wikipedia.org/wiki/CRIME This is one of the defining characteristics of cryptography to me -- there are no perfect cyphers, there are only good systems. Littering extra cryptography around nearly always decreases security. The most secure system is the simplest system that works.
      - madez 12y ago
        Read this thread again. Your statement is not correct since CC never gets to see the plaintext. CC is just a bijective function on (blocksize of KC) bits.
        sirclueless 12y ago
        Did you edit your post? I'm not the only one who misread it. If KC is applied first to the plaintext, then assuming you didn't flub anything in implementation the combined scheme won't be less secure than KC, I agree. Applying CC effectively becomes security through obscurity, which is admittedly sometimes helpful.
        madez 12y ago
        No, sirclueless, I didn't change the scheme I wrote about. Yes, it adds security through obscurity without losing security through well-known recommended ciphers.
  - dustyleary 12y ago
    I need to see a citation for this. Something like the parent article exposing how things get mistakenly broken by applying this concept. It's important to be paranoid about implementing your own crypto, true. But it's not good to take this to dogmatic extremes, ie "never trust any code you write that has crypto in the name or you break everything". I would never write and deploy a custom cypher. But if I did, and my custom cipher CC, when applied to ciphertext encrypted by AES, somehow leaked any information about the plaintext, then I have accidentally made a cryptanalysis breakthrough that has thwarted hundreds of professional crypto people. This is unlikely.
    - deleted 12y ago
      [deleted]
    - deleted 12y ago
      [deleted]
    - stouset 12y ago
      In madez's case, his construct is provably secure, with some caveats. Specifically, the first cipher must be a secure cipher, and the keys for both ciphers must be independent. If the latter is not the case, the custom cipher could very easily leak bits of the key, which would allow the original cipher to be broken. But more importantly, it's the implementation of this construct that's likely to introduce weaknesses. As I posted in my direct reply to him, the problem is that no real world protocol is so simple, and he will now have to implement this. See OpenSSL for what can go wrong when implementing ciphers; and that's a highly-used, generally stable project that's had the benefit of multiple eyeballs for years.
      - rudolf0 12y ago
        Exactly. And if the first cipher is a secure cipher, with no obvious sign it'll be broken any time soon (like AES), why not just use it instead of wrapping it over some homebrew solution?
        madez 12y ago
- kelson 12y ago
  This is almost always less secure than KC alone, when KC is a well-known secure cipher. A simple example would be a CC that hex-encodes the plaintext before applying some transformation on the data (before you laugh, this exists in enterprise systems today). This means CC would effectively expand the underlying data 200% (0xA1 -> 0x4131) and substantially degrade the security of a block-based cipher (32-bit block -> effectively 16-bits). Here's a link to a practical case of unsafe composition (in hashing): http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html http://blog.ircmaxell.com/2015/03/security-issue-combining-b... A bit more detail on randomly composing encryption algorithms: http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html http://blog.cryptographyengineering.com/2012/02/multiple-enc... edit: It would be better to compose CC(KC(P)) so CC can't leak any information about P or degrade KC. Any reluctance to show the world the output of CC should suggest the low-practical-value of CC.
  - madez 12y ago
    CC doesn't get to see the plaintext in the construct I explained. CC is just a bijective function on (blocksize of KC) bits. The author of the mentioned blog ignores the fact that cascading ciphers like I described breaks automated cryptoanalysis which is a necessity for mass surveillance in a world with wide-spread cryptography.
    - sarciszewski 12y ago
      Cascade Ciphers were out of scope. Moxie was addressing the order of operations for authentication and encryption.
    - kelson 12y ago
      You're right; I misread your construct as KC(CC(P)). Your construct [CC(KC(P))] shouldn't be weaker than KC, unless information or resources are shared by CC and KC (such as keys). Shared information or resources may introduce side channel attacks. Per the previous link, this is likely only practicable on entirely separate machines. Any entity that can break AES at-scale will undoubtedly find any unreviewed cryptographic protocol trivial to break. Any such at-scale effort would already include attacks against typical bad-custom-crypto (because they're extremely easy and common), in addition to the AES attacks. Cascading ciphers, particularly weak ones, will not stop the NSA. edit: addressed information leak if CC & KC share keys/resources
- stouset 12y ago
  Technically, you're correct. In the real world, you're not. This mythical protocol just encrypts a blob and sends it over the wire. But real protocols involving cryptography are significantly more complicated, because they often need to authenticate other parties, cryptographically bind all the messages in a session, preserve forward secrecy, preserve anonymity of one of the communicating parties, etc. Now the problem isn't that you are simply applying your own cipher to the output of a strong cipher. It's that you've now got to implement a damn protocol, because nothing in the world supports your cipher. And that implementation is inevitably going to have more exploitable flaws than a well-maintained open-source project that doesn't implement your bogocipher. Cryptography is hard, and it's not just the primitives that are ripe for gotchas. Combining primitives, implementing primitives, designing protocols, implementing protocols, and generally anything involving touching something anywhere in the entire stack is fraught with danger. As a rule, the more crypto-related lines of code you write, the more likely it is you have introduced weaknesses rather than added strength.
  - madez 12y ago
    Technically correct is the best way of correct. I never suggested my proposal for public protocols for communication between two random parties. I first and all wanted to show the root of this thread wrong. I'd suggest it maybe for highly confidential communication that warrants the trouble.
    - stouset 12y ago
      Technically correct is usually the least useful kind of correct. The root of this thread is extremely sound advice. Don't touch your own crypto unless you're an expert. If you're at the point where your security requirements are so sensitive that you can't possibly risk a break in an underlying well-known cipher, you should hire a real cryptographer and not dick around with inventing your own laughably-broken ciphers. And once you have that cryptographer under your employ, you can feel free to break the rule of not rolling your own crypto. Although that cryptographer is infinitely more likely to simply compose well-known strong ciphers over deploying their own unpublished ones.
- Strilanc 12y ago
  Most of the responses seem to be talking about A -> Custom -Strong -> Unstrong -> Uncustom instead of A -> Strong -> Custom -> Uncustom -> Unstrong*. Some potential problems with applying a custom transform to the cyphertext: - The custom transform might have effects on cache that create opportunities for timing attacks - The custom transform might have a buffer-overflow (just like any other excess code) - The custom transform might support features exploitable in DOS attacks, like run-length encoding - The custom transform might be slow, costing time and money - Sometimes applying two transforms is equivalent to encrypting with a different key (e.g. DES has this property). Might create meet-in-the-middle attacks. - If the custom transform is given the same key as the strong crypto, as a lazy programmer might do, it could leak the key - Switching the ordering of the transforms is a deadly mistake, but easy to glance over - If the strong transform starts with an HMAC, as it should, that can be used to break the custom transform's key anyways (see the post we're commenting on) Mostly those are small things. But the security benefit you get is also small.
  - madez 12y ago
    > Most of the responses seem to be talking about A -> Custom -Strong -> Unstrong -> Uncustom instead of A -> Strong -> Custom -> Uncustom -> Unstrong*. Yes :( > Some potential problems with applying a custom transform to the cyphertext: > - The custom transform might have effects on cache that create opportunities for timing attacks > - The custom transform might have a buffer-overflow (just like any other excess code) This are for the point of my comment irrelevant implementation details. You could apply the custom transform on another computer. > - The custom transform might support features exploitable in DOS attacks, like run-length encoding The custom transform ought to be a bijective function on (blocksize of Strong) bits. > - The custom transform might be slow, costing time and money It was never meant as a suggestion for wide-spread usage. > - Sometimes applying two transforms is equivalent to encrypting with a different key (e.g. DES has this property). Might create meet-in-the-middle attacks. > - If the custom transform is given the same key as the strong crypto, as a lazy programmer might do, it could leak the key The custom transform shouldn't know at all about anything of the strong cipher. Another implementation detail. > - Switching the ordering of the transforms is a deadly mistake, but easy to glance over Another implementation detail. > - If the strong transform starts with an HMAC, as it should, that can be used to break the custom transform's key anyways (see the post we're commenting on) I just wanted to show the common idea of "cryptography is black magic, you should never touch it, you can only do bad things" wrong. My scheme adds security through obscurity which may be worth the trouble.
- angry_octet 12y ago
  So wrong. Your custom cipher could be leaking key material in the encrypted output, almost certainly leaks the key via timing channels, could be leaking the known cipher key by timing channels and more (and this is assuming separate keys). The CC decode stage will be subjected to every possible edge case to see if it will do something dumb, like the oracle attacks mentioned in the article. And it could also leak information about the KC decode via timing attacks. If this was for offline file encryption, where you do the steps separately, maybe okay. But not for online encryption where chosen plaintext is possible.
  - madez 12y ago
    Read this thread. CC is a bijective function on (blocksize of KC) bits. CC knows nothing at all about KC. Implementation can be done in another computer without security problem while you get obscurity. Read this thread.
    - angry_octet 12y ago
      You don't mention separate computers until now. It's a big difference. I thought we were discussing implementing crypto, not some theoretical properties you achieve when conditions are just right. I'm not saying trust the Windows implementation of AES, you can put it through some other cipher with a strong implementation as well, but don't just make up your own one.
sarciszewski 12y ago
> Use a pre-existing cryptography package that has been written properly instead. Okay, name one that has been written properly that the average web developer is going to encounter. I'm going to focus on PHP because that's what I know best, it has an enormous market share, and I'm not a fan of blowing smoke (which I would be if I tried to speak to, e.g. Perl development). PGP? OTR? Axolotl? These aren't part of your standard dev environment. Mcrypt? Hasn't been touched since 2007. There is at least a patch for a bug in the 64-bit implementation of CAST-256 that has been sitting, unmerged, for six years. Libsodium is the best we have, and you need PECL access to install it. OpenSSL is labyrinthine. http://stackoverflow.com/a/29331937/2224584 http://stackoverflow.com/a/29331937/2224584 It's still messy, despite the past year of attention from the security industry, but it's getting better. This library offloads its underlying cryptography to OpenSSL because it's the best we got: https://github.com/defuse/php-encryption/ https://github.com/defuse/php-encryption/ Maybe Python, Ruby, and Node developers have better options available to them. But 83% of the Internet runs PHP, and having a properly written cryptography package just isn't a trivial bar to leap over.
- corndoge 12y ago
  Considering that the original comment never specified web developers, you seem to be responding to an argument that wasn't made.
  - anon4 12y ago
    His point does bear consideration - the expert-written libraries are only expert-usable. You can still badly mess up encryption even if your basic building blocks are written perfectly. It's not just the algorithms that need to be expertly written, it's the way they're combined that also needs to be expertly written and the latter part doesn't exist. OpenSSL allows you to shoot yourself in the foot pretty easily, like choosing very weak ciphers, calculating the mac of the plaintext, etc. OpenSSL is still too low-level for the generic developer. You want things like HTTPS, using which is still too complicated for most people (hello certificate management), but you can get it right more easily by following an online tutorial. Basically anything that is more complicated than "open socket to destination, here's my certificate" is doomed to be misused by non-experts. Oh, and it better have strong default settings so it won't pick RC4 as the cipher or something.
TorKlingberg 12y ago
This article is clearly written for the experts who are implementing cryptography.
- billyhoffman 12y ago
  On its face I guess it is. But really, this is just another demonstration of maxim "Don't do work for untrusted parties". Yes, this applies to cryptography, but also to network protocol design, and even software design in general. Recursive DNS lookup DoS attacks? You are doing work for some you don't know (random UDP packets) The recent NTP DDoS amplification issues? Doing work for someone you don't know (Again. unauth-ed UDP packet trigging craploads of work) Padded Oracle attacks in Crypto? Doing work for someone you don't know, and leaking data based on when something fails. IP Source routing? Doing work for an untrusted party! The moral of this story is verify what you have before you work on it. It all comes down to validating user input and user source.
bradleyjg 12y ago
That's good advice, and I've given it myself, but that doesn't mean you shouldn't read and play around with cryptography if it interests you. I implemented a simplified version of the referenced Vaudenay attack as part of Dan Boneh's Cryptography I course on courseara+. The course was very interesting, and also fun. I'm not ready to go out and implement my own cryptography, but knowing a bit about the subject makes me a more intelligent consumer of crypto libraries. While warning people away from implementing their own cryptography we have to make sure we don't scare people off from the subject altogether. After all, absolute top experts have to start somewhere. + https://www.coursera.org/course/crypto https://www.coursera.org/course/crypto
- classicsnoot 12y ago
  Thank you for the link and the review. I start my CS degree in the Fall; i hope i can start and finish this before then.
  - pmalynin 12y ago
    For the love of all that is sacred, take advanced math and linear algebra.
    - rcthompson 12y ago
      I heartily agree with this sentiment. I have a friend who's a few years older than I am. He majored in CS, and told me in retrospect that he wished he had majored in mathematics instead. I took his advice, and, instead of doing CS major + a few math classes, I did math major + a few CS clases. I am now very glad that I did so. (For context, my friend and I are both data analysts now.)
      - pmalynin 12y ago
        My comment comes from experience of being in progress of doing an Honors CS - Honors Math double major. After having completed Honors Calculus I/ II, Honors Linear Algebra Imy /II circuits in my first year I felt about 2-3 years ahead in my knowledge of mathematics and associated rigor -- this was especially evident when I was taking combined CS/EE courses and seeing student struggle with concepts that I thought were basic (infinimums, supremums, etc.) but apparently are not covered over the course of 2 years in the regular streams.
bachback 12y ago
what kind of "experts"? like NIST experts or experts at Microsoft? this a non-sensical meme in cryptography. it all comes down to the value at risk. at some price point you can hire people i.e. invest the resources to get it right. the reality is that many security libraries and principles are ancient and infrequently updated, that much of the research in the field is academic and useless. I think its much better to think in terms of risks. good security usually doesn't more value than bad security, until there is a breach.
- angry_octet 12y ago
  Yeah, you got it, the people at NIST and M$ are going to do better than you. 'Academic and useless' research huh? Go read DJB's website some day, it is far from inapplicable. All the research that publicly disclosed HUGE holes in SSL? I think it's incredibly important. As to good security being of little value, maybe ask Sony and Adobe (and even NSA) if they wished they had better security.
bitL 12y ago
Even experts can go terribly wrong; there are known embarrassing attacks that invalidated algorithms considered rock-solid for 10 years by some bright 15-year old students. Would you prevent those brights from tackling on better ways to do crypto because they aren't "top experts" yet? Most likely they will just run away in disgust and park their capabilities in less hostile field. Celebritism doesn't really work in science; it only prevents progress.
- 3am 12y ago
  1) Experts in all fields are always wrong sometimes. The nonexperts are wrong more frequently on average and people are less interested in proving them wrong. 2) Saying that implementing your own cryptography usually implies a production environment. I think it's generally assumed that nobody cares what people do with their own time/personal projects. 3) Trite sounds bites don't work in science either, and expert -/-> celebrity.
  - bitL 12y ago
    Ad 2) most groundbreaking projects you know originated as messy ad-hoc personal projects and not in production-sanitized environments (look even at GPG, embarrassingly for crypto community with one almost bankrupt developer). Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down and point to obvious flaws that can be fixed in minutes by someone experienced, while keeping the new idea intact. The crypto requires such an enormous amount of talent that it is bright individuals, not companies, that make things move there, and quite often the more people involved, the worse results.
    - deleted 12y ago
      [deleted]
    - stouset 12y ago
      > someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down I'm sorry, but this is essentially never the case. This is no different than in other fields, for instance math or physics, where complete novices come in every day believing they've had a completely novel idea that will revolutionize the field. 999,999 times out of a million they haven't, and in the one remaining case they've come up with a solution in search of a problem. "Oh, you've come up with a new cipher? Congratulations. Assuming it is secure, why should we use it ? Is it faster than existing ones? Simpler and more likely to be implemented correctly? Resistant to timing attacks? Resistant to CPU power analysis? Resistant to differential cryptanalysis? Suitable for low-CPU and low-memory embedded devices? Oh, none of these things? Gee, how interesting." I'm reminded of http://www.scottaaronson.com/blog/?p=304 http://www.scottaaronson.com/blog/?p=304
chm 12y ago
What constitutes a "top expert"? I'd want the people writing cryptography software to have made mistakes and learned from them. That's how the software gets better, no? Of course, there's a theoretical minimum to be familiar with.

kkl 12y ago

The "Don't roll your own crypto" mantra is overly ambiguous and enforces the culture of elitism in information security. I hope that something displaces this regurgitated "advice" with something more helpful. I know Moxie's article is a few years old but it is a step in the right direction regardless. --EDIT-- I don't think I was perfectly clear in my original comment. I attempted to expand on my position in a follow-up comment: https://news.ycombinator.com/edit?id=9376131 https://news.ycombinator.com/edit?id=9376131

madez 12y ago
This. The problem is that in this community you are witch-hunted if you talk about crypto and you are not a famous cryptographer. People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem).
- daeken 12y ago
  > People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem). I've been dealing with crypto on a near-daily basis for the last 15 years. I'm well within the top percentile of understanding of the subject, from a theoretical and practical standpoint, having worked to break cryptographic protocols for most of my life. I wouldn't trust myself to design a crypto protocol for grocery lists, let alone anything important. This isn't false modesty or elitism or ignorance. It's recognizing that even if every smart person I know looks at it and says it's fine, it probably isn't. Crypto isn't hard to get right -- that's actually not the argument that anyone will make -- but it's impossible to know if you did get it right or not. You do not have the knowledge required to build safe cryptographic protocols. Neither does anyone else on this site.
  - madez 12y ago

richo 12y ago

If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.

sas 12y ago
it's like Pascal's Wager for security
deleted 12y ago
[deleted]
- deleted 12y ago
  [deleted]
kkl 12y ago
I do not have concerns with the mantra itself just it's usage and the entitlement that often comes along with using it. The top answer on this Stack Exchange question is a good example of what I believe to be proper usage of the mantra. http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own http://security.stackexchange.com/questions/18197/why-should...
a1a 12y ago
Schneier's Law comes to mind "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." https://www.schneier.com/blog/archives/2011/04/schneiers_law.html https://www.schneier.com/blog/archives/2011/04/schneiers_law...
- kleer001 12y ago
  Oh, that's what that is! I had found a similar thing making my own puzzles, "It's easy to make a puzzle you can't solve, but it's hard to make a puzzle that's fun." Well, that' not entirely the same thing, but they overlap I guess.
- derefr 12y ago