Make the public key unrecoverable given the private key

Question

OpenSSL seems to bundle the private key together with the public key when it produces .pem files. Is there a way to prevent this from happening; i.e. prevent OpenSSL from creating a .pem private key with the public key in it? According to Wikipedia RSA's public key is not directly derivable from the private key.

The specific usage scenario is: I'm creating a little service where everybody can ssh tunnel to a server to anti-block. To facilitate this (and make it automagic) I distribute a SSH private key with my program that it uses to then log into one of the servers. We don't need to authenticate our users - anybody can use the private key to log in and the user has no permissions other than open up a tunnel - but we do need to prevent against MITMs. known_hosts is not good since our servers are on dynamic IPs that are distributed with something that isn't DNS. So, the thing we want to keep secret is our "authorized_keys" file which contains the public key for login. But any attacker can just use PuTTYgen to generate the public key from the private key and set up a MITM server that the user can successfully authenticate to...

Answer 1

For the commonly used cryptographic algorithms, the public key can be recomputed from the private key. An edge case can be a RSA key with a big public exponent (i.e. not the traditional 65537) and without knowledge of the modulus factors. This contradicts the standard storage format described in PKCS#1; not knowing the factors means that private key operations won't be optimized with the CRT, so signatures and decryption will take four times as much CPU; and, last but not least, public exponents which do not fit on 32 bits will not be supported by some widespread RSA implementations (the CryptoAPI in Windows, namely).

Therefore, it does not seem practical to try to "hide" the public key from the private key holder.

---

In your case, you cannot prevent a MitM attack from the server side, and even if you could "hide" the public key, then this would buy you nothing: the attacker could mount a modified server which accepts every user as "valid" regardless of the public key they use to authenticate. If you want to protect your users against a MitM, have their software verify that it talks to the right server, i.e. yours. This is what plain SSH does with the known_hosts file. If you cannot use this facility but cannot distribute a modified SSH client either, then you will have to rely on user education: teach them that when they connect to your server and their client (e.g. PuTTY) grumbles about the server key not being known, make them verify the "key fingerprint" which the client will display: it should match the fingerprint of your server key.

Answer 2

Distribute a public key with the software. Have the client verify that the server's private key corresponds to the public key embedded in the software. You aren't really gaining anything by having the private key embedded in the software as it is trivial to extract the private key from the software and thus anyone could pretend to be your software. The better thing is to simply make sure that any unaltered client will know to only connect to your server via storing the public key.

Answer 3

Don't fight the protocol. Can you prevent MitM, by distributing your public SSH_host_key with your software? The SSH tunneling should use strict host verification using your hostkey. If your host key changes, it will stop working, so you might need a way that they can get the latest hostkey (in a secure way).