Il semble que ce soient tous deux des algorithmes de cryptage qui nécessitent des clés publiques et privées. Pourquoi choisirais-je l'un par rapport à l'autre pour fournir le chiffrement dans mon application client-serveur?
Réponses:
Le
cryptage et le décryptage RSA RSA sont commutatifs
et peuvent donc être utilisés directement comme schéma de signature numérique
étant donné un schéma RSA {(e, R), (d, p, q)}
pour signer un message M, calculer:
S = M puissance d (mod R)
pour vérifier une signature, calculer:
M = S puissance e (mod R) = M puissance ed (mod R) = M (mod R)
RSA peut être utilisé à la fois pour le cryptage et les signatures numériques,
simplement en inversant l'ordre dans lequel les exposants sont utilisés: l'exposant secret (d) pour créer la signature, l'exposant public (e) pour que quiconque vérifie la signature. Tout le reste est identique.
DSA (Digital Signature Algorithm)
DSA est une variante des algorithmes ElGamal et Schnorr crée une signature de 320 bits, mais avec une sécurité de 512-1024 bits, la sécurité repose à nouveau sur la difficulté de calculer des logarithmes discrets a été assez largement acceptée
DSA Key Generation d'
abord partagée au public mondial les valeurs clés (p, q, g) sont choisies:
choisissez un grand premier p = 2 puissance L
où L = 512 à 1024 bits et est un multiple de 64
choisissez q, un facteur premier de 160 bits de p-1
choisissez g = h power (p-1) / q
pour tout h1
puis chaque utilisateur choisit une clé privée et calcule sa clé publique:
choisissez x calculer y = g puissance x (mod p)
La génération de clés DSA est liée à El Gamal, mais un peu plus complexe. Principalement en raison de l'utilisation du module secondaire q de 160 bits utilisé pour accélérer les calculs et réduire la taille de la signature résultante.
Création et vérification de signature DSA
pour signer un message M
générer une clé de signature aléatoire k, k calculer
r = (g puissance k (mod p)) (mod q)
s = k-1.SHA (M) + xr (mod q)
envoyer signature (r, s) avec message
pour vérifier une signature, calculer:
w = s-1 (mod q)
u1 = (SHA (M) .w) (mod q)
u2 = rw (mod q)
v = (g power u1.y puissance u2 (mod p)) (mod q)
si v = r alors la signature est vérifiée
La création de signature est à nouveau similaire à ElGamal avec l'utilisation d'une clé de signature temporaire par message k, mais en effectuant d'abord calc mod p, puis mod q pour réduire la taille du résultat. Notez que l'utilisation de la fonction de hachage SHA est ici explicite. La vérification consiste également à comparer deux calculs, encore une fois un peu plus complexes que, mais liés à El Gamal.
Notez que presque tous les calculs sont mod q, et sont donc beaucoup plus rapides.
Mais, contrairement à RSA, DSA ne peut être utilisé que pour les signatures numériques
Sécurité DSA
La présence d'un canal subliminal existe dans de nombreux schémas (ceux qui nécessitent un nombre aléatoire pour être choisi), pas seulement DSA. Il met l'accent sur la nécessité d'une «sécurité du système», pas seulement d'un bon algorithme.
Vérifiez la réponse d'AVA ci-dessous .
Ma vieille réponse semble fausse
En référence à man ssh-keygen, la longueur d'une clé DSA est limitée à exactement 1024 bits pour rester conforme à la norme FIPS 186-2 du NIST. Néanmoins, des clés DSA plus longues sont théoriquement possibles; FIPS 186-3 les autorise explicitement. De plus, la sécurité n'est plus garantie avec des clés RSA ou DSA d'une longueur de 1024 bits.
En conclusion, une clé RSA de 2048 bits est actuellement le meilleur choix.
L'établissement d'une connexion SSH sécurisée implique plus que la sélection d'une technologie de paire de clés de cryptage sécurisée. Au vu des révélations de la NSA d'Edward Snowden, il faut être encore plus vigilant que ce qui était auparavant jugé suffisant.
Pour ne citer qu'un exemple, l'utilisation d'un algorithme d'échange de clés sécurisé est tout aussi importante. Voici un bel aperçu des meilleures pratiques de durcissement SSH actuelles .
ssh-keygenpermettent également d'autres clés de taille en bits (j'utilise moi-même une clé DSA 2048 bits générée à l'aide ssh-keygende RHEL).