SHA, RSA et la relation entre eux
SHA est le mécanisme de hachage. Cependant, RSA est l'algorithme de chiffrement.
L'algorithme RSA utilise donc SHA mécanisme de hachage pour générer des clés de hachage qui à leur tour sont utilisées pour crypter le message ??
De plus, RSA lui-même donne 2 clés. L'un peut être gardé public et l'autre privé. Maintenant, ces clés peuvent être utilisées pour crypter et décrypter. Réf: RSA . Alors à quoi sert SHA dans RSA?
Dans un certificat donné par n'importe quel site qui donne la sécurité HTTPS, il y a un SHA ainsi qu'une clé MD5 présente. Comment sont-ils produits et utilisés dans le cryptage ou le décryptage des données transférées au navigateur ?
RSA est en fait deux algorithmes, un pour le chiffrement asymétrique et un pour les signatures numériques (l'algorithme de signature est traditionnellement - mais incorrectement - décrit comme "chiffrement avec la clé privée "et ceci est une source infinie de confusion).
Le chiffrement asymétrique utilise des clés. Les clés sont des paramètres de l'algorithme; l'algorithme lui-même est le même pour tout le monde (en termes de logiciel, c'est le fichier exécutable) tandis que les clés varient selon les utilisateurs. Dans une paire de clés, la clé publique est la clé utilisée pour crypter données (convertir une donnée , c'est-à-dire une séquence d'octets, dans une autre séquence d'octets insondable pour tout le monde) tandis que la clé privée est la clé qui permet de déchiffrer les données ( c'est-à-dire inverser le cryptage).
Alors qu'en chiffrement symétrique , les clés de chiffrement et de déchiffrement sont identiques, mais avec chiffrement asymétrique, les clés de chiffrement et de déchiffrement sont distincts les uns des autres (d'où le nom); ils sont mathématiquement liés entre eux, mais il devrait être impossible (c'est-à-dire trop difficile à faire avec un simple groupe d'ordinateurs) de récupérer la clé de déchiffrement à partir de la clé de chiffrement. C'est pourquoi la clé de chiffrement peut être rendue publique tandis que la clé de déchiffrement est gardée privée: révéler la clé publique ne révèle pas la clé privée.
Ce que le chiffrement asymétrique permet de réaliser n'est pas une mince affaire. La possibilité de révéler la clé publique sans en dire trop sur la clé privée, mais de telle sorte que les deux clés fonctionnent ensemble (ce qui est chiffré avec la clé publique peut être déchiffré par la clé privée correspondante, mais aucune autre), nécessite beaucoup de mathématiques! RSA est plein de mathématiques. Cela contraste avec les algorithmes de chiffrement symétriques qui ne sont "que" des façons de faire un gros gâchis de données en mélangeant les bits ensemble.
Le chiffrement asymétrique est l'outil naturel à utiliser lorsque nous voulons permettre des transmissions confidentielles entre deux utilisateurs au sein d'une grande population. Si vous avez 1000 utilisateurs et que vous souhaitez que l'un des deux utilisateurs puisse échanger des données sans permettre à quiconque de les espionner (y compris les 998 autres utilisateurs), la solution classique serait de distribuer des clés pour le chiffrement symétrique à chaque paire utilisateurs. Alice et Bob auraient une clé commune connue; Alice et Charlie auraient également une clé partagée (pas la même); Bob et Charlie aussi; etc. Chaque utilisateur devrait se souvenir de sa "clé partagée" avec tous les autres des 999 autres utilisateurs, et vous auriez 499500 clés au total. L'ajout d'un 1001e utilisateur impliquerait la création de 1000 clés symétriques supplémentaires et en donnerait une à chacun des 1000 utilisateurs existants. Toute la distribution des clés se transforme bientôt en cauchemar inutilisable/irréalisable. Avec cryptage asymétrique cependant, les choses sont beaucoup plus simples en termes de distribution de clés: chaque utilisateur n'a qu'à se souvenir de sa propre clé privée; et les clés publiques (étant publiques) peuvent être distribuées par une sorte de diffusion (par exemple un annuaire).
RSA a quelques contraintes opérationnelles. Avec la variante la plus utilisée (celle connue sous le nom de PKCS # 1 v1.5 ), si la taille de la clé RSA est "1024 bits" (ce qui signifie que la composante mathématique centrale de la paire de clés est un 1024 bits), alors RSA peut chiffrer un message d'une longueur maximale de 117 octets et produire un message chiffré d'une longueur de 128 octets. Cette taille limitée et l'augmentation de la taille lors du chiffrement sont des conséquences inévitables de la structure mathématique du processus de chiffrement RSA. En raison de ces contraintes, nous ne chiffrons généralement pas les données directement avec RSA; à la place, nous sélectionnons une petite séquence d'octets aléatoires, que nous appelons clé de session. Nous chiffrons la clé de session avec RSA; puis nous utilisons la clé de session avec un algorithme de chiffrement symétrique pour traiter le message entier. Cela s'appelle cryptage hybride .
SHA est le nom commun d'une famille de fonctions de hachage cryptographiques . Le tout premier membre de cette famille a été décrit sous le nom de "SHA" mais a rapidement été déprécié après y avoir trouvé une faiblesse grave; une version fixe a été publiée sous le nom SHA-1 (la version faible est familièrement connue sous le nom de SHA-0). Plus tard, quatre nouvelles fonctions de type SHA ont été ajoutées à la famille (SHA-224, SHA-256, SHA-384 et SHA-512: collectivement appelés "SHA-2").
Les fonctions de hachage n'ont pas de clé. Une fonction de hachage est un algorithme exécutable qui est du code pur. Il y a un SHA-1 et tout le monde utilise le même.
Les fonctions de hachage font "simplement" un gros gâchis des données d'entrée, qui ne sont pas destinées à être démêlées. En fait, il est censé être résistant à l'effilochage. Même si tout le monde sait tout ce qu'il faut savoir sur une fonction de hachage (il n'y a pas de clé, seulement du code, et rien n'est secret), il s'avère toujours "trop difficile" de recalculer un message d'entrée correspondant, étant donné le sortie de fonction de hachage. Il est même impossible de trouver deux messages d'entrée distincts qui, lorsqu'ils sont donnés à la fonction de hachage, produisent la même sortie; il existe doit de telles paires de messages - appelées collisions - car une sortie de fonction de hachage a une petite taille fixe, tandis que les entrées acceptées peuvent être beaucoup plus grandes, il y a donc plus d'entrées possibles que de sorties possibles. C'est une certitude mathématique que des collisions existent pour chaque fonction de hachage, mais en trouver une est une autre affaire.
Une fonction de hachage, en elle-même, ne fait rien de grande valeur immédiate, mais c'est un bloc de construction très important pour d'autres algorithmes. Par exemple, ils sont utilisés avec signatures numériques . Une signature numérique "prouve" l'action consciente d'un signataire désigné sur un élément de données; comme le chiffrement asymétrique, cela implique des paires de clés et des mathématiques, et les contraintes associées sur les données signées. Une fonction de hachage h est telle que la signature h (m) est aussi bonne que la signature m elle-même: puisqu'elle est impossible de trouver deux messages distincts qui ont la même valeur de hachage, l'approbation de la sortie de hachage est assez bonne. Le fait étant que la sortie de la fonction de hachage est suffisamment petite pour être utilisable avec les mathématiques cachées dans l'algorithme de signature, même si le message lui-même est gros (SHA-1 peut traiter des gigaoctets de données et donne une sortie de 20 octets).
On peut noter que certaines variantes récentes de l'algorithme de chiffrement RSA (avec le "remplissage OAEP" de PKCS # 1 v2.0) utilisent en interne des fonctions de hachage. Les fonctions de hachage sont de bons "randomiseurs" (la sortie d'une fonction de hachage ne présente pas de structure reconnaissable), ce qui les rend appropriées pour la construction d'algorithmes cryptographiques plus élaborés avec de bonnes fonctionnalités de sécurité.
Dans SSL/TLS (HTTPS est juste un tunnel HTTP dans un tunnel SSL/TLS), les fonctions de hachage sont utilisées pour plusieurs choses:
- dans le cadre du chiffrement asymétrique et/ou des signatures numériques;
- dans le cadre de HMAC pour permettre au client et au serveur de vérifier que les données échangées n'ont pas été modifiées en transit;
- comme brique de construction pour une fonction de dérivation de clé , qui "étend" une clé de session donnée en plusieurs clés symétriques utilisées pour le chiffrement symétrique et les vérifications d'intégrité dans les deux directions du tunnel.
Le KDF repose sur la "randomisation" et la non-inversibilité de la fonction de hachage. Dans SSL/TLS jusqu'à TLS 1.1, le KDF est construit sur deux fonctions de hachage, MD5 et SHA-1, dans une tentative de le rendre robuste même si des faiblesses ont été trouvées plus tard dans MD5 ou SHA-1. Il s'avère que des faiblesses ont été trouvées dans les deux, mais cela n'a permis aucune interruption sur le KDF tel qu'utilisé dans SSL/TLS. Néanmoins, TLS 1.2 est passé à un autre KDF qui utilise une seule fonction de hachage configurable, généralement SHA-256, pour laquelle aucune faiblesse n'est actuellement connue.
SHA n'est pas utilisé dans RSA.
Cependant, les protocoles cryptographiques comme SSL, SSH et autres utilisent différents algorithmes comme SHA et RSA à des fins différentes. SSL utilise RSA (cryptage) ou DH (avec signature RSA, DSA ou ECDSA) pour la clé négociation et AES ou 3DES pour le chiffrement des données Dans le format de protocole/fichier PGP, RSA, DSA et ElGamal sont utilisés pour la signature et le chiffrement.
Comme vous l'avez noté, ce sont deux choses différentes. Le hachage (SHA) vise à garantir l'intégrité et le chiffrement des données (RSA) pour la confidentialité des données. Ils sont utilisés conjointement pour s'assurer que les données ne sont pas gâchées et que seule la bonne partie est en mesure de les lire.
HTTPS est une forme de PKI, qui fournit l'intégrité, la confidentialité, l'authentification. SHA ou MD5 ne sont que deux algorithmes de hachage différents utilisés pour garantir l'intégrité des connexions https.
Bien sûr, il est possible que SHA soit utilisé pour construire un PRNG (générateur de nombres pseudo aléatoires) pour générer les clés RSA. Mais il est possible d'utiliser d'autres primitives cryptographiques (par exemple AES) également. Pour cela PRNG il y a des spécifications spéciales (NIS SP 800-90, ANSI X9.31). Le "pur" RSA don peu importe comment la clé est générée, mais pour appliquer RSA dans une application réelle, nous devons être sûrs que la clé générée doit être générée par un processus aléatoire vrai (ou semble être généré par). Sinon, pour un attaquant, il est facile de devinez quelles sont les clés (si les keays ne sont pas aléatoires, l'attaquant peut également les calculer).
RSA est un algorithme de cryptographie asymétrique, ceux-ci sont utilisés pour envoyer des informations à une partie spécifique sans même que vous ne puissiez les déchiffrer à nouveau. Mais peut toujours être déchiffré par l'autre personne. Ces algorithmes sont très lents et ne veulent donc être utilisés que sur de petites quantités de données.
SHA est une suite d'algorithmes de hachage cryptographique, c'est une représentation plus petite d'un grand bloc de données, à des fins cryptographiques, nous voulons que cela réponde à l'exigence qu'il est impossible de trouver un ensemble de données tel qu'il corresponde à un hachage donné (dans en d'autres termes, vous ne pouvez pas passer du hachage aux données qui produisent ce hachage (qu'il s'agisse des mêmes données ou non).
Enfin, il existe des algorithmes comme AES, ils sont utilisés en cryptographie symétrique où les deux côtés ont la même clé et peuvent à la fois crypter et décrypter avec la même clé.
Fondamentalement, nous assemblons ces différentes choses de différentes manières: nous allons donc utiliser RSA pour envoyer et convenir d'un ensemble de clés symétriques (AES) (juste pour une session), de cette façon, personne d'autre ne peut décrypter nos données, mais l'autre personne car ils ne pouvaient pas mettre la main sur les clés symétriques et nous ne faisons pas la cryptographie asymétrique lente sur toutes les données mais juste une clé de chiffrement symétrique relativement petite.
Le hachage est généralement utilisé dans de tels systèmes de la manière suivante, nous voulons vérifier que les données proviennent de l'autre personne, donc il déchiffre le texte brut avec sa clé privée, si nous chiffrons ce texte chiffré, nous devrions récupérer les données ( Pensez essentiellement au chiffrement comme l'inverse du déchiffrement et cela a tout à coup un sens!), Cependant, comme je l'ai dit plus tôt, la cryptographie asymétrique est lente. Alors, pourquoi ne pas hacher les données et signer le hachage de cette façon, nous pouvons vérifier l'intégrité des données sans que quelqu'un puisse créer des données qui semblent correspondre.