Some professionally designed crypto systems have turned out to have serious flaws. In general, if your system is secret you don’t get the advantage of having the entire crypto community look it over and decide if it is reliable.
Moreover, for many practical applications of cryptography you need to interact with a large number of people who need to have some idea how the protocol works. For example, if I want people to be able to email me in a secure fashion even if I’ve never met them, I need something like an RSA public key. There’s no way around that. Similarly, if I’m a large organization, like say a bank or an online business that needs to send a lot of secure data to a variety of systems, each of those systems needs to know about it. Security by obscurity isn’t just a bad idea in that sort of context, it is essentially impossible.
For example, I learn that RSA’s public key [1] involves a combination of two integers, each with a different use. Then I look at a signed message using the RSA protocol and it’s just a long hex-string, with no clear delimiters on which part means what. YES, I can look this up in a spec—but as an example of what MinibearRex is proposing, what if the public key I associate with a message could be any one of several (two-integer-output) operations on the “public key” string? It’s easy for the recipient to guess a few operations and see if they work with some private key bank.
I’m not sure I follow this line of logic. The way RSA works the sender looks up the recipient’s public key. How do you intend for the sender to decide what to do?
I’m not sure I follow this line of logic. The way RSA works the sender looks up the recipient’s public key. How do you intend for the sender t to decide what to do?
Guess a few (predisclosed, known) permutations of the key. A nightmare for attackers (who have to guess what the public key is), but easy for the recipient to recover.
I’m not sure I follow. If the public key is public, then the attackers don’t have to guess. If the public key isn’t known how is a sender supposed to encrypt it?
The public key is known; its association with a particular user is not. Through a separate channel [1], members of the club were given (the very short message of) transformations they can apply to a real public key. The sender uses the real public key but labels it as having the transformed one. When the ciphertext decrypts to garbage, attackers have to figure out what the real key is, requiring un-automatable analysis.
The recipient need only try a few reverse transformations to get back the true public key.
[1] which makes it unusable for the context of e.g. banks that you discussed, but the topic was theoretical situations where this can increase security
I don’t see what your transformations are buying you. You don’t have to label an encrypted message with its key at all. The intended recipient knows their own key. So your proposal is equivalent to telling your “public” key only to people who are supposed to send you messages.
Some professionally designed crypto systems have turned out to have serious flaws. In general, if your system is secret you don’t get the advantage of having the entire crypto community look it over and decide if it is reliable.
Moreover, for many practical applications of cryptography you need to interact with a large number of people who need to have some idea how the protocol works. For example, if I want people to be able to email me in a secure fashion even if I’ve never met them, I need something like an RSA public key. There’s no way around that. Similarly, if I’m a large organization, like say a bank or an online business that needs to send a lot of secure data to a variety of systems, each of those systems needs to know about it. Security by obscurity isn’t just a bad idea in that sort of context, it is essentially impossible.
I’m not sure I follow this line of logic. The way RSA works the sender looks up the recipient’s public key. How do you intend for the sender to decide what to do?
Guess a few (predisclosed, known) permutations of the key. A nightmare for attackers (who have to guess what the public key is), but easy for the recipient to recover.
I’m not sure I follow. If the public key is public, then the attackers don’t have to guess. If the public key isn’t known how is a sender supposed to encrypt it?
The public key is known; its association with a particular user is not. Through a separate channel [1], members of the club were given (the very short message of) transformations they can apply to a real public key. The sender uses the real public key but labels it as having the transformed one. When the ciphertext decrypts to garbage, attackers have to figure out what the real key is, requiring un-automatable analysis.
The recipient need only try a few reverse transformations to get back the true public key.
[1] which makes it unusable for the context of e.g. banks that you discussed, but the topic was theoretical situations where this can increase security
I don’t see what your transformations are buying you. You don’t have to label an encrypted message with its key at all. The intended recipient knows their own key. So your proposal is equivalent to telling your “public” key only to people who are supposed to send you messages.