Le chiffrement symétrique et asymétrique sont des opérations distinctes qui opèrent dans des contextes distincts, pour des usages distincts et des modèles d'attaque distincts. Il n'y a guère de sens à prétendre que l'un ou l'autre est "plus sécurisé" que l'autre (cela exigerait d'abord une sorte de mesure de sécurité quantifiée, ce qui n'est pas facile à définir).

Le chiffrement asymétrique est plus exigeant : il s'agit de réaliser le chiffrement et de pouvoir publier les moyens de chiffrer (la clé publique) sans révéler les moyens de déchiffrer (la clé privée). Une implémentation pratique nécessite des mathématiques, alors que le cryptage symétrique est principalement de brouiller les choses (remarquez, il est difficile de faire un bon travail de brouillage; mais encore, moins de mathématiques sont impliquées).

Systèmes couramment déployés (par exemple SSL / TLS) combinent le cryptage asymétrique et le cryptage symétrique (et quelques autres choses également) dans des protocoles qui font le travail prévu (par exemple, "tunnel bidirectionnel avec confidentialité, intégrité et authentification ").

Il y a un sens dans lequel vous pouvez définir la force d'un algorithme de chiffrement particulier¹: en gros, la force est le nombre de tentatives qui doivent être faites pour casser le chiffrement. Plus précisément, la force est la quantité de calcul qui doit être faite pour trouver le secret. Idéalement, la force d'un algorithme est le nombre de tentatives de force brute qui doivent être faites (pondérées par la complexité de chaque tentative, ou réduites si une sorte de parallélisation permet de multiples tentatives pour partager une partie du travail); à mesure que les attaques contre l'algorithme s'améliorent, la force réelle diminue.

Il est important de réaliser que «l'algorithme de chiffrement particulier» inclut la prise en compte d'une taille de clé spécifique. Autrement dit, vous ne lancez pas RSA contre AES, mais RSA 1024 bits (avec un mode de remplissage spécifique) avec AES-256 (avec un mode de chaînage spécifique, IV, etc.). En ce sens, vous pouvez demander: si j'ai une copie de mes données cryptées avec l'algorithme A avec des valeurs données des paramètres P et Q (en particulier la taille de la clé), et une copie cryptée avec l'algorithme B avec les paramètres P et R, alors lequel de (A, Pval₁, Qval₁) et (B, Pval₂, Rval₂) est susceptible d'être craqué en premier?

En pratique, de nombreux protocoles impliquent l'utilisation de plusieurs primitives cryptographiques. Différentes primitives ont différentes utilisations possibles, et même lorsque plusieurs primitives peuvent remplir une fonction donnée, il peut y en avoir une qui convient mieux que d'autres. Lors du choix d'une primitive cryptographique dans un but donné, le processus de décision se déroule un peu comme ceci:

1. Quels algorithmes peuvent faire le travail? → Je peux utiliser A ou B ou C.
2. De quelle force ai-je besoin? → Je veux 2 ^N opérations, donc j'ai besoin de la taille de clé L _A pour la primitive A, L _B pour la primitive B, L _C pour C. primitif
3. Compte tenu de mes contraintes (vitesse brute, latence, efficacité de la mémoire,…), lesquelles de celles-ci (L _A -bit A ou L _B -bit B ou L _C -bit C) est le meilleur?

Par exemple, disons que votre exigence est un protocole d'échange de données avec une partie en laquelle vous ne faites pas confiance. Ensuite, la cryptographie symétrique ne peut pas faire le travail seule: vous avez besoin d'un moyen de partager la clé. La cryptographie asymétrique telle que RSA peut faire le travail, si vous laissez les parties échanger des clés publiques à l'avance. (Ce n'est pas la seule possibilité, mais je n'entrerai pas dans les détails ici.) Vous pouvez donc décider de la longueur de clé RSA qui a la bonne force pour votre application. Cependant, RSA est lent et encombrant (par exemple, il n'y a pas de protocoles standard pour appliquer le cryptage RSA à un flux - principalement parce que personne ne s'est dérangé parce qu'ils seraient si lents). De nombreux protocoles courants impliquant la cryptographie à clé publique ne l'utilisent que pour échanger un secret de durée limitée: une clé de session pour un algorithme de cryptographie symétrique. C'est ce qu'on appelle le chiffrement hybride. Encore une fois, vous choisissez la durée de la clé de session en fonction de la force souhaitée. Dans ce scénario, les deux primitives impliquées ont tendance à avoir la même force.

¹ _{La même notion s'applique à d'autres utilisations de la cryptographie, comme la signature ou le hachage.}

Le choix entre le cryptage symétrique et asymétrique dépend du cas d'utilisation .

Le cryptage symétrique est utilisé pour partager des informations entre un ensemble de personnes auxquelles tous auront accès. De plus, le cryptage symétrique est agréable car il est plus facile à comprendre (moins susceptible de le gâcher) et les algorithmes ont tendance à être plus rapides.

Le cryptage asymétrique est utilisé lorsqu'un grand nombre de sous-ensembles de personnes peuvent partager l'information. En outre, la cryptographie asymétrique peut être utilisée à l'envers pour signer des documents. Ceci est particulièrement intéressant car cela permet aux gens de certifier qu'une clé publique appartient à une certaine personne.

Dans un ensemble de 10 personnes, permettre à chaque paire de personnes de communiquer en toute sécurité, nécessite 45 clés uniques (9+ 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1). Et maintenant, pensez à Internet au lieu du petit groupe de 10 personnes. Il est évident que cela ne peut pas être géré avec des clés symétriques.

Dans le monde réel, les deux types sont souvent combinés. Une approche asymétrique est utilisée pour confirmer l'identité d'un partenaire de communication et pour transmettre quelque chose qui se traduira par une clé symétrique. Cette clé symétrique est ensuite utilisée pour un cryptage performant des données réelles.

En général, les schémas de chiffrement asymétriques sont plus sécurisés car ils nécessitent à la fois une clé publique et une clé privée.

Non. Tu ne peux pas dire ça. C'est baloney. Ce n'est tout simplement pas vrai.

La force est indépendante de symétrique ou asymétrique. La cryptographie symétrique et la cryptographie asymétrique sont deux types d'outils cryptographiques différents. Chacun peut être faible ou fort, selon. Il n'y a aucune raison pour que la cryptographie asymétrique soit nécessairement plus forte que la cryptographie symétrique.

Par exemple:

• AES est plus sûr contre les attaques cryptanalytiques que RSA 512 bits, même si RSA est asymétrique et AES symétrique.

• RSA 4096 bits est plus sûr contre les attaques cryptanalytiques que RC4 40 bits, même si RC4 est symétrique et RSA asymétrique.

Je suis d'accord avec ce que Thomas a déclaré ci-dessus. Le cryptage symétrique et asymétrique sont des opérations distinctes.

Le cryptage symétrique est moins coûteux que le cryptage asymétrique. Cher car il nécessite moins de traitement. Pour être exact, je fais référence au processus de décryptage.

Et c'est pourquoi SSL / TLS utilise une combinaison de cryptage symétrique et asymétrique. Le cryptage / décryptage asymétrique entre deux pairs lors d'une transaction SSL / TLS ne se produit que lors de la négociation initiale. Une fois que les deux pairs ont convenu d'une clé privée partagée, le reste de la communication utiliserait un cryptage symétrique. Ce faisant, la seule opération coûteuse aura lieu lors de la prise de contact initiale et le reste de la communication utilisera un cryptage symétrique qui nécessite moins de ressources.

Dans le cryptage asymétrique avec cryptographie à clé publique, il y a un échange de clés publiques qui pourraient être interceptées par un homme du milieu. C'est une faiblesse majeure, que le cryptage symétrique n'a pas. Puisque le gouvernement américain effectue une surveillance de masse, il y a une réelle possibilité que le MIM soit monnaie courante. L'utilisation de clés prédéterminées avec des algorithmes symétriques et l'utilisation de nombres réellement générés de manière aléatoire semblerait moins vulnérable que de se fier à l'échange de clés publiques.