4 ms·

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 involvin

by 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.
  - madez 12y ago
    So I think it comes down to whether the root > I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. is a sound advice. I disagree with this advice strongly. Tinkering around with cryptography can teach you a lot. Especially if you are not a top expert. Furthermore, I described a relatively simple protocol that monotonically increases the security of a communication by applying a custom cipher. I didn't add the restrictions that CC must not know anything about KC anything because I though that would be clear. Interestingly, you get security through obscurity on top of the previous security from my scheme even when CC is trivial like swapping the nibbles in bytes and then xoring a constant. This makes untargeted mass-surveillance in case of broken KC a lot harder. Depending on the CC it's relatively easy to make it totally impractical. I think my scheme is interesting because it's unintuitive that it adds any security.
    - stouset 12y ago
      Nobody is arguing against tinkering with cryptography as a mechanism for learning. This advice is meant to stop people from writing homebrew encryption for real-world, production systems. You described a relatively simple protocol that, at worst, does not decrease security in a theoretical sense with at least one critically-important and unmentioned caveat (don't use the same or related keys for both ciphers). In a practical sense, your simple protocol is likely a security disaster. In the absolute best case, it really only defends against a break in the underlying cipher that is so thoroughly devastating that ciphertexts can be decrypted essentially for free. Even DES hasn't been broken this badly, and it's been considered broken for decades. The reason this is the case is that such a simple transform is only useful against an entity that is automatically decrypting ciphertexts on the wire en masse, and who isn't looking for your data specifically. Against a targeted adversary who can "merely" break AES with substantial effort, the additional cost such a transform would impose is completely negligible. In your example of a transform on top of a TLS connection, it would be completely obvious through packet analysis that the protocol was TLS, and your transform would be trivially understood and reversed after watching a few handshakes.
    - bandrami 12y ago

by stouset 12y ago

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.
- madez 12y ago
  So I think it comes down to whether the root > I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. is a sound advice. I disagree with this advice strongly. Tinkering around with cryptography can teach you a lot. Especially if you are not a top expert. Furthermore, I described a relatively simple protocol that monotonically increases the security of a communication by applying a custom cipher. I didn't add the restrictions that CC must not know anything about KC anything because I though that would be clear. Interestingly, you get security through obscurity on top of the previous security from my scheme even when CC is trivial like swapping the nibbles in bytes and then xoring a constant. This makes untargeted mass-surveillance in case of broken KC a lot harder. Depending on the CC it's relatively easy to make it totally impractical. I think my scheme is interesting because it's unintuitive that it adds any security.
  - stouset 12y ago
    Nobody is arguing against tinkering with cryptography as a mechanism for learning. This advice is meant to stop people from writing homebrew encryption for real-world, production systems. You described a relatively simple protocol that, at worst, does not decrease security in a theoretical sense with at least one critically-important and unmentioned caveat (don't use the same or related keys for both ciphers). In a practical sense, your simple protocol is likely a security disaster. In the absolute best case, it really only defends against a break in the underlying cipher that is so thoroughly devastating that ciphertexts can be decrypted essentially for free. Even DES hasn't been broken this badly, and it's been considered broken for decades. The reason this is the case is that such a simple transform is only useful against an entity that is automatically decrypting ciphertexts on the wire en masse, and who isn't looking for your data specifically. Against a targeted adversary who can "merely" break AES with substantial effort, the additional cost such a transform would impose is completely negligible. In your example of a transform on top of a TLS connection, it would be completely obvious through packet analysis that the protocol was TLS, and your transform would be trivially understood and reversed after watching a few handshakes.
  - bandrami 12y ago