Fournir n'importe quelle partie de la clé privée la rend moins sécurisée, au moins marginalement, simplement parce qu'elle fournit à un attaquant un espace clé potentiel plus petit à explorer.

J'échoue pour comprendre ce que vous voulez réaliser. La seule chose que deux personnes doivent faire pour vérifier si elles détiennent les mêmes informations est d'échanger un hachage.

Si vous concevez un protocole et que vous êtes préoccupé par les attaques de relecture, vous pouvez vous protéger contre celui-ci en effectuant une réponse de défi à l'aide d'un HMAC.

Modifier :

Comme suggéré dans les commentaires et expliqué dans la réponse perspicace de DW, je dois souligner que l'impact sur la sécurité de votre clé privée dépendra BEAUCOUP de l'algorithme exact que vous utilisent. Dans le pire des cas, ne révélant qu'une petite partie de la clé privée cassera complètement la sécurité de cette clé.

La révélation d'une partie de la clé privée peut être catastrophique, pour certains cryptosystèmes asymétriques (à clé publique). Le niveau exact de risque dépend exactement du cryptosystème que vous utilisez. Quelques exemples:

• Si vous utilisez RSA avec e = 3 pour la clé publique, alors révéler 1 / 4ème de la clé privée (les 1/4 bits de d) est suffisamment pour permettre à un attaquant de reconstruire l'intégralité de la clé privée. Par exemple, si vous utilisez RSA 2048 bits et que vous révélez les 512 bits les moins significatifs de la clé privée, un attaquant peut récupérer le reste de votre clé privée. Ce résultat est dû à Boneh, Durfee et Frankel. Il y a d'autres résultats similaires dans la littérature (par exemple, sur les bits les plus significatifs, un sous-ensemble aléatoire de bits, etc.).

• Avec DSA, si quelques bits sont fuite du nonce utilisé dans chaque signature (pour une variété de signatures), cela suffit pour récupérer la clé privée. Par exemple, si vous pouvez observer 5 bits du nonce secret qui a été utilisé dans chacune des 4000 signatures, cela suffit pour récupérer une clé privée ECDSA de 384 bits. Cela ne révèle pas exactement la clé privée (cela révèle une autre valeur secrète générée lors de la signature), mais c'est similaire.

Je réalise que d'autres réponses disent que ce n'est pas un problème. Ces réponses peuvent supposer que vous utilisez un cryptosystème à clé symétrique. Pour la plupart des cryptosystèmes à clé symétrique, si vous révélez une partie de la clé, mais qu'une quantité suffisante de la clé reste non révélée, ils seront probablement toujours sécurisés. En ce qui concerne les cryptosystèmes asymétriques, les choses sont différentes. D'autres réponses semblent supposer que la force brute (essayer de manière exhaustive toutes les clés privées possibles) est la meilleure attaque possible contre le cryptosystème. Pour de nombreux cryptosystèmes asymétriques, cette hypothèse n'est pas exacte.

À quelle vitesse un attaquant pourrait-il casser la clé avec ces 8 caractères?

Il est difficile de répondre sans savoir de quel type de clé nous parlons et de quel algorithme il est utilisé avec.

Dans le cas d'un cryptage symétrique où la clé est entièrement aléatoire (comprendre que chaque bit prend une part égale dans l'incertitude globale de la clé), alors cela dépend principalement de ce que "1 char" représente de données binaires. En général, en révélant n bits , vous réduisez efficacement le nombre de clés possibles d'un facteur d'au moins 2 ^ n .

• Dans le cas d'une représentation textuelle binaire où 1 caractère = (0 ou 1) = 1 bit : 8 caractères signifie un facteur de réduction de 2 ^ 8 = 256 .
• Dans le cas d'une représentation hexadécimale où 1 caractère = 4 bits : 8 caractères signifie un facteur de réduction de 2 ^ 32 = 4294967296 .
• Dans le cas d'une représentation base64 où 1 caractère = 6 bits : 8 caractères signifie un facteur de réduction de 2 ^ 48 = 281474976710656 .

Qui - selon la quantité d'informations révélées - peut (ou non) être utilisé comme un levier pour casser votre clé en fonction des éventuelles faiblesses (actuelles ou futures) de votre algorithme de cryptage.

Notez également que dans le cas d'un cryptage asymétrique où la clé n'est pas complètement aléatoire (par exemple module de facteur premier et exposant en RSA), révéler n bits peut en fait révéler beaucoup plus d’informations utiles et peut entraîner une perte de sécurité catastrophique.

Mais la vraie question est:

Pourquoi quelqu'un aurait-il besoin de faire ça?

Non seulement cette méthode pose une sécurité potentielle défaut, la fiabilité ne semble pas correspondre à votre objectif, qu'en est-il des 248 bits restants?

La méthode que vous décrivez est juste une fonction de hachage très simple qui est complètement continue (très mauvaise pour le contrôle d'intégrité) et partiellement réversible (très mauvaise pour des raisons de sécurité).

Si vous vraiment doit le faire, utiliser une fonction de hachage cryptographique sécurisée et largement disponible, telle que SHA-256 , qui générera un hachage beaucoup plus sécurisé (pratiquement irréversible et intensif en calcul) et beaucoup plus résistant aux collisions que "les 8 premiers caractères".

Si vous utilisez un chiffrement asymétrique, vous ne devriez jamais avoir besoin trop partager n'importe quelle partie (même un hachage) de la clé privée, utilisez la clé publique à la place .

Je dirais que cela va de "pas critique, mais plutôt stupide" à "désastreux", selon ce que signifie "8 caractères" et selon les algorithmes utilisés.

Si l'on lit " 8 caractères "comme ce qu'ils sont littéralement, 64 bits, alors vous réduisez la taille de votre clé de 64 bits (c'est un peu moins drastique si l'on suppose" char "comme caractère encodé en base 64, alors ce ne serait que 48 bits).

En supposant que "clé privée" se réfère en fait à un algorithme symétrique (peu probable?), c'est probablement tolérable car 192 bits sont bien au-delà de la force brute. Mais là encore, pourquoi utiliser une clé de 256 bits en premier lieu?

En supposant que "clé privée, 256 bits" signifie que vous utilisez une sorte de crypto à courbe elliptique (pour les chiffrements symétriques, "privé" fait peu car toutes les clés sont privées, et pour RSA et al.256 bits est bien trop petit pour être utile), vous abaissez votre niveau de sécurité d'un peu moins de 128 bits (ce qui est, actuellement, irréalisable) à un peu moins de 96 bits. Ce qui est ... enfin, pas précisément faisable, mais presque. Étant donné que l’informatique quantique n’est pas encore tout à fait là mais qu’elle est en route, «pas tout à fait, mais presque» est un peu désastreux.
Après tout, ce que l’on prévoit est le pire des cas, pas le meilleur des cas .

C'est encore plus désastreux que cela est absolument, 100% inutile.

Si deux parties partagent une clé secrète, une méthode très évidente pour s'assurer que c'est la même clé serait de crypter un motif de bits aléatoires suffisamment long (plus long que la sortie de hachage), de laisser l'autre côté décrypter le motif de bits et de renvoyer un hachage sécurisé (disons, SHA-256, SHA3, peu importe) du motif de bits.
Ce que la première partie peut comparer trivialement au résultat du calcul du hachage sur le motif aléatoire d'origine.

A aucun moment la clé privée (ou une partie de celle-ci) n'est transmise, ni même un hachage de ladite clé (ce qui pourrait très très peu probable, mais éventuellement, être inversé ou fournir un indice vers une partie de celle-ci), et depuis il sont des bits d'entrée plus aléatoires que des bits de sortie, il est impossible de déterminer le modèle de bits d'origine qui a été haché à partir de la valeur de hachage, et de l'utiliser pour obtenir un angle sur le chiffrement.

L'attaquant ne peut que voir un modèle de bits aléatoire pour lequel il a besoin de connaître la clé (inconnue) pour obtenir l'original, et le hachage d'un autre modèle de bits inconnu qui pourrait être l'un des nombreux modèles de bits (sans aucun moyen de savoir lequel).

D'autres ont déjà répondu par la quantité d'informations divulguées et par conséquent par la diminution de l'entropie pour un attaquant; et le point principal qu'il faut comparer (publiquement) les hachages a également été noté.

Cependant, cela suppose que les deux personnes souhaitant comparer les clés se font confiance. S'ils ne se font pas confiance, le problème est que si A envoie du hachage (K) à B, B peut savoir que A a le même, ou un K différent de B, mais il peut tricher et renvoyer le même hachage, faire penser à A à tort que B est également en possession de la même clé.

Une solution à ce problème est que A envoie du hachage (K) à B, et s'attend à ce que B envoie du hachage (pas K) à A , où non K est la valeur inversée au niveau du bit de K. B ne peut envoyer ce hachage à A que s'il possède vraiment K.

REMARQUE Ce qui suit suppose une accélération linéaire (telle qu'elle serait obtenue dans une attaque par force brute) - l'accélération peut être EXPONENTIELLEMENT PLUS, selon l'algorithme.

Il est très difficile de comprendre les grands nombres - même j'ai été surpris quand la réponse est venue. Voici une façon d'y penser:

Si, sans aucune information, il faudrait 13,8 milliards d'années (l'âge de l'univers jusqu'à présent) pour casser une clé, à l'aide de 8 caractères binaires, cela ne prendrait que 0,023 seconde.

C'est: 13,8 milliards d'années / 2 ^{(bits_per_symbol * number_of_symbols)} .

Vous dit que le nombre de symboles est de "8 caractères", et je suppose que le binaire, qui a 8 bits par symbole. donc: 13,8 milliards d'années / 2 ^{(8 * 8)}

S'ils sont uuencodés, ou base64, ils auront 6 bits par symbole, donc cela leur prendrait tous les 25 minutes pour travailler sur les combinaisons restantes.

Ces proportions s'appliquent uniquement au nombre de bits que vous avez révélés, et quelle que soit la durée de la clé (seulement que la clé prendrait 13,8 milliards d'années à se fissurer ).

L'intérêt de la cryptographie à clé publique est que vous n'avez JAMAIS JAMAIS besoin de partager la clé privée. Chaque clé privée ne doit exister qu'à un seul endroit et ne doit jamais traverser un réseau. L'envoi de clés va à l'encontre du principe même de la cryptographie à clé publique. Il n'est JAMAIS nécessaire d'envoyer des clés privées, partiellement ou non.

Si vous voulez que deux (ou plus) appareils différents puissent décoder le même message, demandez à chacun de créer sa propre clé privée, envoyez-vous leur clé publique (en toute sécurité !!) puis crypter le message avec les deux clés. Habituellement, avec PKC, les messages longs sont chiffrés à l'aide d'un chiffrement symétrique avec une clé aléatoire, et la clé est ensuite chiffrée avec PKC et envoyée avec le message; vous pouvez facilement chiffrer la clé aléatoire avec plusieurs clés publiques et les envoyer toutes avec le même message.

Si tout ce que vous voulez faire est de montrer que vous avez la clé privée, vous pouvez faire ce qui suit:

Demandez à la personne à qui vous voulez le prouver de fournir une valeur aléatoire (un "nonce") . Ajoutez votre propre valeur aléatoire, hachez-la et signez le hachage. Renvoyez votre valeur aléatoire et la signature.

Votre homologue prendra alors le nonce qu'il a envoyé, plus votre valeur aléatoire, le hachera et vérifiera la signature par rapport à votre clé publique.

L'inclusion d'une valeur aléatoire de l'expéditeur prouve que vous n'avez pas simplement sélectionné une valeur qui a été précédemment signée par le véritable propriétaire.

N'acceptez EN AUCUNE CIRCONSTANCE quelque chose envoyé par quelqu'un d'autre, et le signer, sans aucun changement. Ils peuvent vous envoyer l'empreinte digitale d'un document qu'ils ont écrit, et vous signerez effectivement ce document.

Si Alice et Bob soupçonnent qu'ils partagent la même clé privée, alors pourquoi pas:

1. Alice génère nonce X.
2. Alice crypte X pour elle-même - Y.
3. Alice envoie X, Y à Bob.
4. Si Alice et Bob ont vraiment la même clé privée, alors quand Bob déchiffrera Y, il obtiendra X. Maintenant, Bob sait qu'Alice partage son clé privée.
5. Bob fait de même en sens inverse. Maintenant, Alice sait que Bob partage sa clé privée.

Je ne suis pas un expert en cryptographie. Suis-je en train de manquer quelque chose?

Je pense que ce qui précède satisfera leur question sans dévoiler leurs secrets. Eve ne connaîtra pas non plus la réponse à la question.