Can a public key have a different length (encryption) than the private key?

Question

I have a 1024 bits private key, and use it to generate a public key. Does that automatically mean that my public key also has 1024 encryption? Or can it be of a lesser encryptio

Answer 1

No. The public key in a key pair always matches the private key size, in fact it is derived from the private key.

However, with some public key cryptographic implementations, such as OpenPGP, keys are created with subkeys assigned to different tasks. Those subkeys can be different sizes to each other and the master key used to create them. In those cases the public key data will indicate the key sizes for the master key and the subkey(s) which will match the corresponding private key data.

Whereas many other public key implementations do not utilise subkeys (e.g. TLS) so you will only ever see the single key size. Again that key size will be indicated in both the public and private key data.

The only variation in key sizes you will see is when asymmetric encryption is used in conjunction with symmetric encryption. The symmetric encryption (session key) will be smaller, but it uses entirely different algorithms (e.g. AES, TWOFISH, etc.) and is not part of the public key (except in OpenPGP, where symmetric cipher preferences can be saved because it does not utilise a live connection to establish the symmetrically encrypted communication and exchange session key data).

EDIT: More detail on the relationship between the public and private key data (also known as proving David wrong)

Pointing to RSA is all very well and good, but it depends on the key exchange protocol and for that we go to Diffie-Hellman key exchange and the original patent, which is now expired. Both of these have examples and explanations of the key exchange methods and the relationship between the public and private keys.

Algorithms implementing this relationship, including RSA and El-Gamal, all create both the public and private keys simultaneously. Specifically by creating a private key which then generates the public key. The public key inherits all the features of the private key which made it. The only way to get mis-matched details between the two components would be by somehow generating a public key independently of the private key. The problem there, of course, is that they would no longer be a key pair.

The key generation descriptions for both RSA and El-Gamal explain the common data between the public and private keys and specifically that all the components of the public key are a part of the private key, but the private key contains additional data necessary to decrypt data and/or sign data. In El-Gamal the public components are G, q, g and h while the private components are G, q, g, h and x.

Now, on to the lack of mention of the bit size of the key pairs in the algorithms, yes, that's true, but every practical implementation of them incorporates the selected key size as one of the constants when generating the private key. Here's the relevant code (after all the options are selected, including selecting the key size and specifying the passphrase) for generating keys in GnuPG:

static int
do_create( int algo, unsigned int nbits, KBNODE pub_root, KBNODE sec_root,
           DEK *dek, STRING2KEY *s2k, PKT_secret_key **sk, u32 timestamp,
       u32 expiredate, int is_subkey )
{
  int rc=0;

  if( !opt.batch )
    tty_printf(_(
"We need to generate a lot of random bytes. It is a good idea to perform\n"
"some other action (type on the keyboard, move the mouse, utilize the\n"
"disks) during the prime generation; this gives the random number\n"
"generator a better chance to gain enough entropy.\n") );

  if( algo == PUBKEY_ALGO_ELGAMAL_E )
    rc = gen_elg(algo, nbits, pub_root, sec_root, dek, s2k, sk, timestamp,
         expiredate, is_subkey);
  else if( algo == PUBKEY_ALGO_DSA )
    rc = gen_dsa(nbits, pub_root, sec_root, dek, s2k, sk, timestamp,
         expiredate, is_subkey);
  else if( algo == PUBKEY_ALGO_RSA )
    rc = gen_rsa(algo, nbits, pub_root, sec_root, dek, s2k, sk, timestamp,
         expiredate, is_subkey);
  else
    BUG();

  return rc;
}

The slight differences between the three algorithms relate to the values for the items referred to in the published algorithms, yet in each case the "nbits" is a constant.

You'll find the same consistency relating to the key size in the code for generating keys in OpenSSL, OpenSSH and any other system utilising public key cryptography. In every implementation in order to have a matched public and private key pair the public key must be derived from the private key. Since the private key is generated with the key size as a constant, that key size must be inherited by the public key. If the public key does not contain all the correct shared information with the private key then it will be, by definition, not matched to that key and thus the encryption/decryption processes and the signing/verifying processes will fail.