Peut une clé publique ont une longueur différente (cryptage) que la clé privée?

Pas. La clé publique d'une paire de clés correspond toujours à la clé privée de taille, en fait, il est dérivé de la clé privée.

Cependant, avec certains la clé publique implémentations cryptographiques, comme OpenPGP, les clés sont créées avec des sous-clés affectés à des tâches différentes. Ces sous-clés peuvent être de tailles différentes les unes des autres et le maître de la clé utilisée pour les créer. Dans ces cas, la clé publique de données indique les tailles de clé pour la clé principale et la sous-clé(s) qui correspond à la clé privée de données.

Tandis que de nombreux autres clés publiques des implémentations ne pas utiliser les sous-clés (par exemple,TLS) de sorte que vous ne verrez jamais la simple taille de la clé. Encore que la taille de la clé sera indiqué dans le public et le privé, clé de données.

La seule variation des tailles de clé, vous verrez, c'est quand le chiffrement asymétrique est utilisé en conjonction avec un chiffrement symétrique. Le symétrique de chiffrement (clé de session) sera plus petit, mais il utilise des algorithmes totalement différents (par exemple, AES, TWOFISH, etc.) et ne fait pas partie de la clé publique (sauf dans OpenPGP, où chiffrement symétrique préférences peut être sauvé parce qu'il n'utilise pas une connexion en direct à établir la manière symétrique chiffrée de la communication et de l'échange de la clé de session de données).

EDIT: Plus de détails sur la relation entre la clé publique et privée de données (également connu que la démonstration de David tort)

Pointant vers RSA est très bien, mais cela dépend du protocole d'échange de clés et pour que nous allions au L'échange de clés Diffie-Hellman et la brevet original, qui est maintenant expiré. Ces deux ont des exemples et des explications des principales méthodes d'échange et de la relation entre les clés publique et privée.

Algorithmes de mise en œuvre de cette relation, y compris RSA et El-Gamal, toutes les créer à la fois le public et le privé simultanément sur les touches. Plus précisément, par la création d'une clé privée qui génère alors la clé publique. La clé publique hérite de toutes les fonctionnalités de la clé privée qui a fait d'elle. Le seulement façon à obtenir dépareillés de détails entre les deux composants serait en quelque sorte la génération d'une clé publique, indépendamment de la clé privée. Le problème, bien sûr, c'est qu'ils n'auraient plus à être une paire de clés.

La génération de la clé de descriptions pour les RSA et El-Gamal expliquer les données communes entre les clés publiques et privées et plus précisément que tous les composants de la clé publique sont une partie de la clé privée, mais la clé privée contient des données supplémentaires nécessaires pour déchiffrer les données et/ou de signer des données. Dans El-Gamal, le public, les composants sont G, q, g et h, alors que le privé sont G, q, g, h et x.

Maintenant, sur l'absence de mention de la taille en bits de la clé de paires dans les algorithmes, oui, c'est vrai, mais à chaque mise en œuvre pratique d'eux intègre les clés de la taille comme l'une des constantes lors de la génération de la clé privée. Voici le code (après toutes les options sont sélectionnées, y compris la sélection de la taille de la clé et de la spécification de la phrase de passe) pour générer des clés 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;
}

Les légères différences entre les trois algorithmes liés aux valeurs pour les éléments visés dans les algorithmes publiés, mais dans chaque cas, la "nbits" est une constante.

Vous trouverez la même consistance relative à la taille de la clé dans le code pour générer des clés dans OpenSSL, OpenSSH et de tout autre système utilisant la cryptographie à clé publique. Dans chaque mise en œuvre afin de disposer d'un correspondant de clés publique et privée de la paire de clé publique doit être dérivée de la clé privée. Depuis la clé privée est générée avec la taille de la clé comme une constante, que la taille de la clé doit être héritée par la clé publique. Si la clé publique ne contient pas toutes les informations partagées avec la clé privée, puis il sera, par définition, ne correspond pas à celle de la clé et donc le chiffrement/déchiffrement des processus et de la signature/vérification des processus échouera.

J'étais à la recherche de sources différentes, et ma conclusion est que le module (n=p*q) utilisé pour une clé RSA de génération, est le même pour le public et la clé privée. Le module détermine la longueur de la clé pour les deux.

De ce que je comprends, il n'est pas nécessaire que les deux touches de la même taille. Vérifiez ci-dessous pour savoir comment générer des clés:

http://en.wikipedia.org/wiki/RSA_algorithm#Key_generation

Cependant, je crois que si une clé (ou facteur de module) est significativement plus faible qu'il affaiblirait la force contre la cryptanalyse.

Edit:

Cette discussion est devenue sans objet, car l'OP de préciser qu'ils étaient les plus intéressés à la taille du module, qui va naturellement de même pour le chiffrement et le déchiffrement (à l'exclusion de toute bizarre inconnu crypto-systèmes).

Juste pour clarifier mon point de vue, je dis simplement que si e << d (ou d << e), vous pouvez distribuer les clés de différentes tailles de clé. Ils seraient générées par le même algorithme en utilisant les mêmes bits de taille mathématiques (par exemple 256 bits), et, de même, le chiffrement et le déchiffrement aurait besoin du même nombre de bits. Si vous regardez (pour la clarté de l'exposé) les numéros 1 et 128, vous avez un éventail de choix dans la façon de les représenter. Ils pourraient à la fois être de 8 bits ou 1 pourrait être représentée par un nombre quelconque de bits de 1 à 7 bits. Cela pourrait être considéré comme un truc pas cher, à moins que votre méthode de génération de clé garanties que l'ordre de grandeur de d et e serait très différent d'une manière prévisible. Toutefois, comme indiqué, je ne vois pas grand-chose à faire.