5 ms·

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

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 11y ago
[deleted]
deleted 11y ago
[deleted]
stouset 11y 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 11y 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 11y ago
    Because you get obscurity which makes automated cryptoanalysis of your communication a lot harder (if not impossible) which in turn makes untargeted surveillance more expensive.
    - rudolf0 11y ago
      That seems ridiculous for 2 reasons. First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES. Second, if you're assuming the NSA seriously has the capability to break AES within the next 10 years, then obscuring it with a homebrew cipher is pointless, because they've probably already used their AES decryption capability to find many other ways into your system (through a hosting provider, ISP, domain registrar, DNS provider, admin accounts of coworkers...). Even quantum algorithms are only able to halve the bits of the key search space (so 2^256 will become 2^128, which is still mostly infeasible even against a government adversary). I don't think your suggestion would decrease security, if implemented perfectly (which is unlikely), even if the cipher is insecure and vulnerable to cryptanalysis. But I don't think it would increase security either. And since it wouldn't increase it, yet may decrease it in practice due to an implementation flaw which compromises both ciphers, why bother?
      - madez 11y ago
        > First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES. If you can break a set of ciphers it's trivial to determine which was used for a connection, if one was used; You just try each. The whole point is to hide which is the real cipher to make it more costly to attack you. Making it more costly for the attacker is what we want. > Second, (...) This is no argument for or against the scheme I presented. > Even quantum algorithms are only able to halve the bits of the key search space (so 2^256 will become 2^128, which is still mostly infeasible even against a government adversary). Breaking a cipher means to not have to search all the key space. That's the definition of a broken cipher. > I don't think your suggestion would decrease security, if implemented perfectly (which is unlikely), even if the cipher is insecure and vulnerable to cryptanalysis. But I don't think it would increase security either. And since it wouldn't increase it, yet may decrease it in practice due to an implementation flaw which compromises both ciphers, why bother? We disagree on the practicality of implementing it without adding another vulnerability to your system.
bandrami 11y ago
I need to see a citation for this You're looking at it the wrong way. You need to demonstrate for yourself that nothing in your cipher undoes the last round of the underlying cipher.

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

stouset 11y 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 11y 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 11y ago
  Because you get obscurity which makes automated cryptoanalysis of your communication a lot harder (if not impossible) which in turn makes untargeted surveillance more expensive.
  - rudolf0 11y ago
    That seems ridiculous for 2 reasons. First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES. Second, if you're assuming the NSA seriously has the capability to break AES within the next 10 years, then obscuring it with a homebrew cipher is pointless, because they've probably already used their AES decryption capability to find many other ways into your system (through a hosting provider, ISP, domain registrar, DNS provider, admin accounts of coworkers...). Even quantum algorithms are only able to halve the bits of the key search space (so 2^256 will become 2^128, which is still mostly infeasible even against a government adversary). I don't think your suggestion would decrease security, if implemented perfectly (which is unlikely), even if the cipher is insecure and vulnerable to cryptanalysis. But I don't think it would increase security either. And since it wouldn't increase it, yet may decrease it in practice due to an implementation flaw which compromises both ciphers, why bother?
    - madez 11y ago
      > First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES. If you can break a set of ciphers it's trivial to determine which was used for a connection, if one was used; You just try each. The whole point is to hide which is the real cipher to make it more costly to attack you. Making it more costly for the attacker is what we want. > Second, (...) This is no argument for or against the scheme I presented. > Even quantum algorithms are only able to halve the bits of the key search space (so 2^256 will become 2^128, which is still mostly infeasible even against a government adversary). Breaking a cipher means to not have to search all the key space. That's the definition of a broken cipher. > I don't think your suggestion would decrease security, if implemented perfectly (which is unlikely), even if the cipher is insecure and vulnerable to cryptanalysis. But I don't think it would increase security either. And since it wouldn't increase it, yet may decrease it in practice due to an implementation flaw which compromises both ciphers, why bother? We disagree on the practicality of implementing it without adding another vulnerability to your system.

bandrami 11y ago

I need to see a citation for this You're looking at it the wrong way. You need to demonstrate for yourself that nothing in your cipher undoes the last round of the underlying cipher.