> 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.
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.
I described a relatively simple protocol that monotonically increases the security of a communication
Careful. Encryption is decryption, remember. Do any of the rounds of CC undo any of the rounds of KC? Can you verify that bits that were correlated in PT and uncorrelated in KC are still uncorrelated in KC + CC? Does CC change the entropy content of the resulting message? (If it decreases it you have a problem, and most popular ciphers end up with damn near 8 bits per byte in the ciphertext.)
> 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.