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.
- Alice wants to send Bob as message.
- Alice asks Zed to generate a shared_secret_key and Bob a copy of the shared_secret_key.
- 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.
- 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.
- 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.