4 ms·

Most of the responses seem to be talking about A -> Custom -Strong -> Unstrong -> Uncustom instead of A -> Strong -> Custom -> Uncustom -> Unstrong*. Some pote

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.
- kelson 12y ago
  > 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. Per the other thread, this is overwhelmingly likely to decrease overall security without any practical benefit. > My scheme adds security through obscurity which may be worth the trouble. It adds potential side channels and likely no benefit over KC alone. You've sidelined many potential problems by focusing on "if the composition is properly implemented," but that's a huge problem. The likelihood of properly implementing the composition is vanishingly small. It is very likely to be improperly implemented and provide less security than KC alone (and it costs more!)
  - madez 12y ago
    Okay, this is how I'd ad-hoc implement the scheme I described without the security problems you are commenting. A and B know each other and exchange the custom cipher securely. Imagine they each have a Raspberry Pi which does nothing else then to take each IP package sent from the other side and reverse the custom transform on the data. For each package that it sends to the other party it applies the custom transform to the data. Now A and B can route their internet traffic through their Raspberry Pi and get security by obscurity for their communication on top of the usual security. Even if the custom transform is simple, it's overwhelmingly probable that no automated TLS-break-tool will be able to break the custom transformed TLS traffic to the other party.
    - kelson 12y ago
      Was CC and KC both performed on the Pi? That introduces side channel attacks. Does CC include implementation flaws enabling remote access? An attacker may use the Pi to enhance attacks against the system executing KC. Does the Pi include any remotely exploitable flaws? See before. If assume a perfect/non-exploitable CC/Pi, we may not degrade the security of KC. That key word, may, is the problem professional cryptographers spent years analyzing though. If we spent a month thinking about this, we might identify other requirements needed to avoid weakening KC. This is not recommended. Systems which rely upon cipher-obscurity are not secure. Most amateur cryptosystems are trivially defeated without any knowledge of their internals (FBI has some nice articles on cryptanalysis of criminal ciphers). Advising amateurs to rely upon homegrown ciphers is unprofessional and encourages bad risk mitigation strategies. We also disagree about the difficulty of breaking non-keyed bijections (trivial) versus AES-at-scale ("not trivial"). The cost of the latter easily exceeds $1B. The former would take a trained cryptanalyst less than a month. Is your data worth <$10,000?

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.

kelson 12y ago
> 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. Per the other thread, this is overwhelmingly likely to decrease overall security without any practical benefit. > My scheme adds security through obscurity which may be worth the trouble. It adds potential side channels and likely no benefit over KC alone. You've sidelined many potential problems by focusing on "if the composition is properly implemented," but that's a huge problem. The likelihood of properly implementing the composition is vanishingly small. It is very likely to be improperly implemented and provide less security than KC alone (and it costs more!)
- madez 12y ago
  Okay, this is how I'd ad-hoc implement the scheme I described without the security problems you are commenting. A and B know each other and exchange the custom cipher securely. Imagine they each have a Raspberry Pi which does nothing else then to take each IP package sent from the other side and reverse the custom transform on the data. For each package that it sends to the other party it applies the custom transform to the data. Now A and B can route their internet traffic through their Raspberry Pi and get security by obscurity for their communication on top of the usual security. Even if the custom transform is simple, it's overwhelmingly probable that no automated TLS-break-tool will be able to break the custom transformed TLS traffic to the other party.
  - kelson 12y ago
    Was CC and KC both performed on the Pi? That introduces side channel attacks. Does CC include implementation flaws enabling remote access? An attacker may use the Pi to enhance attacks against the system executing KC. Does the Pi include any remotely exploitable flaws? See before. If assume a perfect/non-exploitable CC/Pi, we may not degrade the security of KC. That key word, may, is the problem professional cryptographers spent years analyzing though. If we spent a month thinking about this, we might identify other requirements needed to avoid weakening KC. This is not recommended. Systems which rely upon cipher-obscurity are not secure. Most amateur cryptosystems are trivially defeated without any knowledge of their internals (FBI has some nice articles on cryptanalysis of criminal ciphers). Advising amateurs to rely upon homegrown ciphers is unprofessional and encourages bad risk mitigation strategies. We also disagree about the difficulty of breaking non-keyed bijections (trivial) versus AES-at-scale ("not trivial"). The cost of the latter easily exceeds $1B. The former would take a trained cryptanalyst less than a month. Is your data worth <$10,000?