Quel est le risque de partager publiquement une partie d'une clé privée?
Si deux personnes veulent vérifier qu'elles ont la même clé privée (disons 256 bits), quel est le risque de partager les 8 premiers caractères sur un canal potentiellement public?
Un attaquant peut-il récupérer plus d'informations que ces personnages, et/ou à quelle vitesse un attaquant pourrait-il casser la clé compte tenu de ces 8 caractères?
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 de clé potentiel plus petit à explorer.
Je n'arrive pas à 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 craignez des attaques de réexécution, vous pouvez vous protéger contre lui en effectuant une réponse de défi à l'aide d'un HMAC.
Modifier :
Comme suggéré les commentaires et expliqué dans réponse perspicace de D.W. , je dois souligner que l'impact sur la sécurité de votre clé privée dépendra BEAUCOUP de exactement l'algorithme que vous utilisez. Dans le pire des cas, révéler seulement une petite partie de la clé privée rompra 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 de risque exact 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 bas) est suffisant pour permettre à un attaquant de reconstruire la clé privée entière. 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 existe 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 s'échappent 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 partie suffisante de la clé n'est pas révélée, elle sera probablement toujours sécurisée. En ce qui concerne les cryptosystèmes asymétriques, les choses sont différentes. D'autres réponses semblent supposer que la force brute (en essayant 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.
Combien plus rapide un attaquant pourrait-il casser la clé compte tenu de ces 8 caractères?
Il est difficile de répondre sans savoir de quel type de clé nous parlons et avec quel algorithme il est utilisé.
Dans le cas d'un chiffrement symétrique où la clé est entièrement aléatoire (comprendre que chaque bit participe de manière égale à l'incertitude globale de la clé), alors cela dépend principalement de ce que "1 caractère" représente en termes de données binaires. En général, en révélant n bits, Vous réduisez effectivement 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 character = (0 or 1) = 1 bit: 8 caractères signifie un facteur de réduction de2^8 = 256. - Dans le cas d'une représentation hexadécimale où
1 character = 4 bits: 8 caractères signifie un facteur de réduction de2^32 = 4294967296. - Dans le cas d'une représentation base64 où
1 character = 6 bits: 8 caractères signifie un facteur de réduction de2^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 faiblesses possibles (actuelles ou futures) de votre algorithme de chiffrement.
Notez également que dans le cas d'un chiffrement asymétrique où la clé n'est pas complètement aléatoire (par exemple module du facteur premier et exposant dans RSA), révéler n bits Peut en fait révéler des informations beaucoup plus utiles et peut entraîner une perte catastrophique de sécurité.
Mais la vraie question est:
Pourquoi aurait-on jamais besoin de faire ça?
Non seulement cette méthode pose un problème de sécurité potentiel, mais elle ne semble pas correspondre à votre objectif, qu'en est-il des 248 bits restants?
La méthode que vous décrivez n'est qu'une fonction de hachage très triviale 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 devez le faire, utilisez 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 bien plus résistant aux collisions que "les 8 premiers caractères".
Si vous utilisez un cryptage asymétrique, vous ne devriez jamais avoir besoin de partager une partie (même un hachage) de la clé privée, utilisez plutôt la clé publique .
Je dirais que cela va de "pas critique, mais un peu stupide" à "désastreux", selon ce que signifie "8 caractères" et selon les algorithmes utilisés.
Si l'on lit "8 caractères" tels qu'ils sont littéralement, 64 bits, alors vous réduisez votre taille de clé de 64 bits (c'est un peu moins drastique si l'on suppose "char" comme caractère codé 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?), Cela 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 cryptographie à courbe elliptique (pour les chiffrements symétriques, "privé" n'a pas de sens car toutes les clés sont privées, et pour RSA et al. 256 bits est trop petit pour être utile), vous réduisez votre niveau de sécurité d'un peu moins de 128 bits (ce qui est actuellement impossible) à un peu moins de 96 bits. Ce qui est ... eh bien, pas précisément possible, mais presque. Considérant que l'informatique quantique n'est pas encore tout à fait là mais 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 cas.
C'est encore plus désastreux, car cela est absolument, 100% inutile.
Si deux parties partagent une clé secrète, une méthode très évidente pour s'assurer qu'il s'agit de la même clé serait de crypter un modèle de bits aléatoire suffisamment long (plus long que la sortie de hachage), de laisser l'autre côté décrypter le modèle de bits et renvoyer un fichier sécurisé hachage (par exemple, SHA-256, SHA3, peu importe) du motif binaire.
Que la première partie peut comparer de manière triviale 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é (qui pourrait très très peu probable, mais peut-être, être inversé ou fournir un indice vers une partie de celle-ci), et puisqu'il y a plus de hasard bits d'entrée que les 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 l'utiliser pour obtenir un angle sur le chiffrement.
L'attaquant ne voit qu'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 voulant 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 croire à tort à A 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.
NOTE Ce qui suit suppose une accélération linéaire (telle que celle qui 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 moi, j'ai été surpris lorsque 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 * nombre_de_symboles).
Vous avez 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 codés en uuencode ou base64, ils auront 6 bits par symbole, il leur faudra donc 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 longueur de la clé (seulement que la clé mettrait 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'en un seul endroit et ne 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 autrement.
Si vous voulez que deux (ou plusieurs) appareils différents puissent décoder le même message, demandez à chacun de créer sa propre clé privée, de vous envoyer sa clé publique (en toute sécurité !!) puis de crypter le message avec les deux clés. Habituellement avec PKC, les longs messages sont chiffrés en utilisant 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 crypter 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, c'est montrer que vous avez la clé privée, vous pouvez procéder comme suit:
Demandez à la personne que vous souhaitez 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é signée par le véritable propriétaire précédemment.
NE PAS EN AUCUN CAS accepter quelque chose envoyé par quelqu'un d'autre et le signer, sans aucune modification. 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:
- Alice génère nonce X.
- Alice crypte X pour elle-même - Y.
- Alice envoie X, Y à Bob.
- Si Alice et Bob ont vraiment la même clé privée, alors quand Bob déchiffre Y, il obtiendra X. Maintenant, Bob sait qu'Alice partage sa clé privée.
- 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.