Is it possible to create an asymmetric cryptosystem where the private keys are not easily verifiable as such?

Question

Plaintext that consists of an RSA key is easily recognizable as such, because it satisfies certain mathematical properties, in particular (See the answer for Why can an encrypted private key be brute forced?):

$$d = e^{-1} \mod (p-1)(q-1).$$

Is it impossible to design a public key system where it was harder to verify that the decryption of the key was successful? The usual answer to protect an encrypted key from being brute forced is to use a larger key size, but I thought hard to recognize plain-text is a good property to have in an encryption system?

Answer 1

A key pair (private key and corresponding public key) is always "verifiable" by simply trying to use it. E.g., if this is a key pair for a signature algorithm, then you can try to sign some data with the putative "private" part, and see if the signature can be verified with the "public" part. There is not much you can do about that.

"Hard to recognize plaintext" was thought as a line of defense in cryptosystems from, say, the 1930s. This was before the invention of the computer, hence algorithms had to be performed by hand or through relatively simple electro-mechanical apparatus. Invariably, they were quite weak and needed the extra safety of having a relatively uniform distribution of plaintext data elements. But we are now in 2011, and we have big computers and good algorithms. To state things plainly: if having a "hard to recognize plaintext" makes any difference, then your encryption algorithm sucks.

With a modern symmetric encryption systems (e.g. AES-128 with CBC mode), plaintext internal structure is not an issue.

Answer 2

Elliptic curve private keys are simply scalars, modulo the field size. So there's a slight bias because the field size is slightly smaller than a power of two, but it's minimal.

However, I also echo the previous commentator that using such properties for security is probably unwise.

Answer 3

This answer is not entirely on topic but not off topic either.

I read the question as, is it possible to design an asymmetric cryptosystem in which the private key is non-verifiable. I believe such a system is possible but it requires changes to the typical asymmetric encryption assumptions. Edit: My third example comes closer to answering the question.

Trivial example: Public keys aren't public. An attacker only has access to cipher-texts and does not have access to the public key. The attacker has to guess both the "public" and private keys because the attacker can not verify the private key without the "public" key.

But you say "thats not fair, if you're going to make the public key a secret why not use symmetric crypto?". Well it has one advantage over symmetric crypto. If the person with your public key is captured previous communications are still confidential. So you say: "Ok, but your trivial example is still not as useful as standard asymmetric encryption."

Less trivial example: Using blind signing you can create a public-key infrastructure which uses a third party to mask Alice's True "public" key from Bob. No one, but the third party, would be able to link Alices true private key to the public key that Bob uses to communicate to Alice. Alice is allowed to have a public key, Bob is allowed to send messages to Alice using this public key but Alice can't decrypt these messages without the help of the third-party. The third party can't read Alices messages. Thus, Alice's private key can't be verified given only Bob's public key. Furthermore, this system is as capable and secure as the typical asymmetric encryption scheme. Note that such a system could be expanded to more than three parties, creating a onion network of public/private keys similar to Tor.

Example that prevents published public keys from verifying secret keys: Create a symmetric/asymmetric hybrid that has three keys partial_public_key, partial_private_key, and shared_secret_key. Under such a system the partial_public_key would not be sufficient to verify the full or partial_private_key.

1. Alice wants to send Bob as message.
2. Alice asks Zed to generate a shared_secret_key and Bob a copy of the shared_secret_key.
3. Since Zed already has a previously exchanged shared_secret_key with Alice and a previously exchanged shared_secret_key with Bob, Zed can securely distribute the new requested shared_secret_key for Alice-Bob communications using our system.
4. Alice uses the shared_secret_key and Bob's partial_public_key to generate the full public_key for Bob, encrypts and sends a message to Bob using the full (generated) public key.
5. Bob uses the shared_secret_key and the partial_private_key to generate a full private key to decrypt the message.

Eve has no way to verify that she has the correct shared_secret_key and therefore can not confirm if she has guessed the correct full private_key (unless Zed helps her).

Alice and Bob can use more than one party (maybe Zed isn't that trustworthy) to generate the shared_secret_key allowing Alice and Bob to spread the trust around. Request 100,000 parties to all generate different shared_secret_keys, xor all the generated shared_secret_keys together to create a single key only knowable if all 100,000 generating parties collude with Eve.