8 ms·

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:

• 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
        What you (and the wiki link) are describing is plaintext -> CC (gzip) -> KC. This is different than the argument you're replying to which is plaintext -> KC -> CC.
    • stouset 12y ago
      If you use the same key for KC and CC, CC can (and hell, in all likelihood probably does) leak bits of the key. So yes, there is a way of breaking this construct when used the way you said.
  • 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.