Pardonnez à un grand naïf cette réflexion, qui me tarabusque depuis pas
mal de temps, et les questions qui s'ensuivent :
Admettons que quelqu'un tente une attaque par "force brute" (ou
dictionnaire) sur un fichier :
1- comment le programme sait-il qu'il doit s'arrêter ?
2- Il regarde dans le fichier si ça ressemble à du non-décrypté ?
3- Si oui, si je crypte deux fois (avec deux clés), est-ce que le
message crypté "ressemble" à du "décrypté raté" ?
4- si oui,le quelqu'un a-t-il les moyens de parvenir à ses fins,
puisqu'il ne verra rien ?
Il y a un "non" quelque-part, bien sûr (sinon je viendrais d'inventer un
top-chouette cryptage...;)
Où est-ce que je me goure ? la "ressemblance" crypté/"décrypté raté" ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc Lasson
Corto wrote:
Bonjour, Salut,
Pardonnez à un grand naïf cette réflexion, qui me tarabusque depuis pas mal de temps, et les questions qui s'ensuivent :
Admettons que quelqu'un tente une attaque par "force brute" (ou dictionnaire) sur un fichier : 1- comment le programme sait-il qu'il doit s'arrêter ? 2- Il regarde dans le fichier si ça ressemble à du non-décrypté ?
Il doit connaître la "forme" du clair (ie. si c'est un texte, une image, un executable ...). Si tu cryptes des lancés de pile ou face (un bit un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton clair.
3- Si oui, si je crypte deux fois (avec deux clés), est-ce que le message crypté "ressemble" à du "décrypté raté" ? 4- si oui,le quelqu'un a-t-il les moyens de parvenir à ses fins, puisqu'il ne verra rien ?
S'il teste par force brute, crypter toujours deux fois ca revient à doubler la taille de la clef.
Pardonnez à un grand naïf cette réflexion, qui me tarabusque depuis pas
mal de temps, et les questions qui s'ensuivent :
Admettons que quelqu'un tente une attaque par "force brute" (ou
dictionnaire) sur un fichier :
1- comment le programme sait-il qu'il doit s'arrêter ?
2- Il regarde dans le fichier si ça ressemble à du non-décrypté ?
Il doit connaître la "forme" du clair (ie. si c'est un texte, une image,
un executable ...). Si tu cryptes des lancés de pile ou face (un bit un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton
clair.
3- Si oui, si je crypte deux fois (avec deux clés), est-ce que le
message crypté "ressemble" à du "décrypté raté" ?
4- si oui,le quelqu'un a-t-il les moyens de parvenir à ses fins,
puisqu'il ne verra rien ?
S'il teste par force brute, crypter toujours deux fois ca revient à
doubler la taille de la clef.
Pardonnez à un grand naïf cette réflexion, qui me tarabusque depuis pas mal de temps, et les questions qui s'ensuivent :
Admettons que quelqu'un tente une attaque par "force brute" (ou dictionnaire) sur un fichier : 1- comment le programme sait-il qu'il doit s'arrêter ? 2- Il regarde dans le fichier si ça ressemble à du non-décrypté ?
Il doit connaître la "forme" du clair (ie. si c'est un texte, une image, un executable ...). Si tu cryptes des lancés de pile ou face (un bit un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton clair.
3- Si oui, si je crypte deux fois (avec deux clés), est-ce que le message crypté "ressemble" à du "décrypté raté" ? 4- si oui,le quelqu'un a-t-il les moyens de parvenir à ses fins, puisqu'il ne verra rien ?
S'il teste par force brute, crypter toujours deux fois ca revient à doubler la taille de la clef.
Quelques points me semblent un peu obscurs cependant :
2- Il regarde dans le fichier si ça ressemble à du non-décrypté ?
Il doit connaître la "forme" du clair (ie. si c'est un texte, une image, un executable ...).
Y'a pas des propriétés "statistiques" qui permettent de déterminer un déchiffrage raté d'un document (autre qu'aléatoire) ? Un texte comporte beaucoup de séquences qui codent une espace, et des séquences de lettres en proportions variables, par exemple. Et puis les formats de fichiers ne sont pas infinis... j'imagine que les programmes qui "déchiffent" les séquences génétiques font ce genre de trucs ?
Si tu cryptes des lancés de pile ou face (un bit > un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton clair.
Donc même une séquence aléatoire est reconnaissable... Donc le crypté n'a pas *tout-à-fait* une allure "aléatoire"... bon, je pige mieux.
S'il teste par force brute, crypter toujours deux fois ca revient à doubler la taille de la clef.
A condition d'employer deux fois le même algorithme, ou d'indiquer quels algorithmes ont utilise... En revanche, si je ne dévoile pas l'algorithe utilisé (je ne parle pas de "sécurité par l'obscurité", qui conduit à utiliser des trucs non fiables, plutôt de non-dévoilement d'information), le gars en face est un peu embêté : c'est comme multiplier encore la clef par le nombre d'algorihtmes utilisables, non ?
(ceci dit, si on me pique le fichier, le programme doit pas être très loin...)
Est-ce que les GPG et autres permettent de faire ce genre de trucs ; je veux dire : choisir une séquence d'algos de chiffrages successifs ? (ce qui reviendrait à avoir une "méta-clé" ?)... mfff, je viens de me relire ; ça a pas beaucoup d'intérêt ; autant allonger la clé de base ?
En tout cas, je pige un peu mieux tout ça, merci beaucoup !
Corto
Merci Marc,
Quelques points me semblent un peu obscurs cependant :
2- Il regarde dans le fichier si ça ressemble à du non-décrypté ?
Il doit connaître la "forme" du clair (ie. si c'est un texte, une image,
un executable ...).
Y'a pas des propriétés "statistiques" qui permettent de déterminer un
déchiffrage raté d'un document (autre qu'aléatoire) ? Un texte comporte
beaucoup de séquences qui codent une espace, et des séquences de lettres
en proportions variables, par exemple. Et puis les formats de fichiers
ne sont pas infinis... j'imagine que les programmes qui "déchiffent" les
séquences génétiques font ce genre de trucs ?
Si tu cryptes des lancés de pile ou face (un bit > un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton
clair.
Donc même une séquence aléatoire est reconnaissable... Donc le crypté
n'a pas *tout-à-fait* une allure "aléatoire"... bon, je pige mieux.
S'il teste par force brute, crypter toujours deux fois ca revient à
doubler la taille de la clef.
A condition d'employer deux fois le même algorithme, ou d'indiquer quels
algorithmes ont utilise... En revanche, si je ne dévoile pas l'algorithe
utilisé (je ne parle pas de "sécurité par l'obscurité", qui conduit à
utiliser des trucs non fiables, plutôt de non-dévoilement
d'information), le gars en face est un peu embêté : c'est comme
multiplier encore la clef par le nombre d'algorihtmes utilisables, non ?
(ceci dit, si on me pique le fichier, le programme doit pas être très
loin...)
Est-ce que les GPG et autres permettent de faire ce genre de trucs ; je
veux dire : choisir une séquence d'algos de chiffrages successifs ? (ce
qui reviendrait à avoir une "méta-clé" ?)... mfff, je viens de me relire
; ça a pas beaucoup d'intérêt ; autant allonger la clé de base ?
En tout cas, je pige un peu mieux tout ça, merci beaucoup !
Quelques points me semblent un peu obscurs cependant :
2- Il regarde dans le fichier si ça ressemble à du non-décrypté ?
Il doit connaître la "forme" du clair (ie. si c'est un texte, une image, un executable ...).
Y'a pas des propriétés "statistiques" qui permettent de déterminer un déchiffrage raté d'un document (autre qu'aléatoire) ? Un texte comporte beaucoup de séquences qui codent une espace, et des séquences de lettres en proportions variables, par exemple. Et puis les formats de fichiers ne sont pas infinis... j'imagine que les programmes qui "déchiffent" les séquences génétiques font ce genre de trucs ?
Si tu cryptes des lancés de pile ou face (un bit > un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton clair.
Donc même une séquence aléatoire est reconnaissable... Donc le crypté n'a pas *tout-à-fait* une allure "aléatoire"... bon, je pige mieux.
S'il teste par force brute, crypter toujours deux fois ca revient à doubler la taille de la clef.
A condition d'employer deux fois le même algorithme, ou d'indiquer quels algorithmes ont utilise... En revanche, si je ne dévoile pas l'algorithe utilisé (je ne parle pas de "sécurité par l'obscurité", qui conduit à utiliser des trucs non fiables, plutôt de non-dévoilement d'information), le gars en face est un peu embêté : c'est comme multiplier encore la clef par le nombre d'algorihtmes utilisables, non ?
(ceci dit, si on me pique le fichier, le programme doit pas être très loin...)
Est-ce que les GPG et autres permettent de faire ce genre de trucs ; je veux dire : choisir une séquence d'algos de chiffrages successifs ? (ce qui reviendrait à avoir une "méta-clé" ?)... mfff, je viens de me relire ; ça a pas beaucoup d'intérêt ; autant allonger la clé de base ?
En tout cas, je pige un peu mieux tout ça, merci beaucoup !
Corto
Marc Lasson
Corto wrote:
Y'a pas des propriétés "statistiques" qui permettent de déterminer un déchiffrage raté d'un document (autre qu'aléatoire) ?
Il existe des tests pour reconnaitre si une suite est aléatoire (ca sert surtout à tester les générateurs pseudo-aléatoire). Je ne suis pas un expert, mais je pense qu'aucun n'est fiable à 100%. (Je pense aussi qu'un fichier aléatoire est incompréssible. A vérifier.)
Si tu cryptes des lancés de pile ou face (un bit > > un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton clair.
Donc même une séquence aléatoire est reconnaissable... Donc le crypté n'a pas *tout-à-fait* une allure "aléatoire"... bon, je pige mieux.
Non, non. Quand je voulais dire "très peu", c'était pour pas dire impossible.
S'il teste par force brute, crypter toujours deux fois ca revient à doubler la taille de la clef.
A condition d'employer deux fois le même algorithme, ou d'indiquer quels algorithmes ont utilise... En revanche, si je ne dévoile pas l'algorithe utilisé (je ne parle pas de "sécurité par l'obscurité", qui conduit à utiliser des trucs non fiables, plutôt de non-dévoilement d'information), le gars en face est un peu embêté : c'est comme multiplier encore la clef par le nombre d'algorihtmes utilisables, non ?
Non, en cryptographie la règle est claire: l'algorithme de chiffrement est publique.
Si tu connais deux algo de chiffrement, l'algo A qui utilise une clef de q bits et l'algo B qui utilise une clef p bits. Si ton nouveau algo révolutionnaire c'est "crypter avec A puis avec B", alors quelqu'un qui veut faire de la force brute, va générer les 2^p clefs de B et les 2^q clefs de A. Et il devra pour chaque clef de B, tester toutes les clefs A ca fait donc au total 2^p + 2^q = 2^(p+q) tests.
Tout se passe comme si ton algorithme utilise une seule clef de p+q bits.
Mais c'est equivalent si le type ne fait que de la force brute. Il est evident que si tu cryptes deux fois avec RSA avec deux clefs de 64 bits, ce n'est pas pareil qu'avec une clef de 128 bits. Deux petites clefs ca se casse plus facilement qu'une grosse.
Est-ce que les GPG et autres permettent de faire ce genre de trucs ; je veux dire : choisir une séquence d'algos de chiffrages successifs ? (ce qui reviendrait à avoir une "méta-clé" ?)... mfff, je viens de me relire ; ça a pas beaucoup d'intérêt ; autant allonger la clé de base ?
Voilà :)
En tout cas, je pige un peu mieux tout ça, merci beaucoup !
De rien.
-- Marc. Si vous voullez m'envoyer un message chiffré, utilisez ma clef publique: (1007, 35).
Corto wrote:
Y'a pas des propriétés "statistiques" qui permettent de déterminer un
déchiffrage raté d'un document (autre qu'aléatoire) ?
Il existe des tests pour reconnaitre si une suite est aléatoire (ca sert
surtout à tester les générateurs pseudo-aléatoire). Je ne suis pas un
expert, mais je pense qu'aucun n'est fiable à 100%. (Je pense aussi
qu'un fichier aléatoire est incompréssible. A vérifier.)
Si tu cryptes des lancés de pile ou face (un bit > > un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton
clair.
Donc même une séquence aléatoire est reconnaissable... Donc le crypté
n'a pas *tout-à-fait* une allure "aléatoire"... bon, je pige mieux.
Non, non.
Quand je voulais dire "très peu", c'était pour pas dire impossible.
S'il teste par force brute, crypter toujours deux fois ca revient à
doubler la taille de la clef.
A condition d'employer deux fois le même algorithme, ou d'indiquer quels
algorithmes ont utilise... En revanche, si je ne dévoile pas l'algorithe
utilisé (je ne parle pas de "sécurité par l'obscurité", qui conduit à
utiliser des trucs non fiables, plutôt de non-dévoilement
d'information), le gars en face est un peu embêté : c'est comme
multiplier encore la clef par le nombre d'algorihtmes utilisables, non ?
Non, en cryptographie la règle est claire: l'algorithme de
chiffrement est publique.
Si tu connais deux algo de chiffrement, l'algo A qui utilise une clef de
q bits et l'algo B qui utilise une clef p bits. Si ton nouveau algo
révolutionnaire c'est "crypter avec A puis avec B", alors quelqu'un qui
veut faire de la force brute, va générer les 2^p clefs de B et les 2^q
clefs de A. Et il devra pour chaque clef de B, tester toutes les clefs A
ca fait donc au total 2^p + 2^q = 2^(p+q) tests.
Tout se passe comme si ton algorithme utilise une seule clef de p+q
bits.
Mais c'est equivalent si le type ne fait que de la force brute.
Il est evident que si tu cryptes deux fois avec RSA avec deux clefs de
64 bits, ce n'est pas pareil qu'avec une clef de 128 bits. Deux petites
clefs ca se casse plus facilement qu'une grosse.
Est-ce que les GPG et autres permettent de faire ce genre de trucs ; je
veux dire : choisir une séquence d'algos de chiffrages successifs ? (ce
qui reviendrait à avoir une "méta-clé" ?)... mfff, je viens de me relire
; ça a pas beaucoup d'intérêt ; autant allonger la clé de base ?
Voilà :)
En tout cas, je pige un peu mieux tout ça, merci beaucoup !
De rien.
--
Marc.
Si vous voullez m'envoyer un message chiffré,
utilisez ma clef publique: (1007, 35).
Y'a pas des propriétés "statistiques" qui permettent de déterminer un déchiffrage raté d'un document (autre qu'aléatoire) ?
Il existe des tests pour reconnaitre si une suite est aléatoire (ca sert surtout à tester les générateurs pseudo-aléatoire). Je ne suis pas un expert, mais je pense qu'aucun n'est fiable à 100%. (Je pense aussi qu'un fichier aléatoire est incompréssible. A vérifier.)
Si tu cryptes des lancés de pile ou face (un bit > > un lancé), il y a (trés) peu de chances que quelqu'un reconnaisse ton clair.
Donc même une séquence aléatoire est reconnaissable... Donc le crypté n'a pas *tout-à-fait* une allure "aléatoire"... bon, je pige mieux.
Non, non. Quand je voulais dire "très peu", c'était pour pas dire impossible.
S'il teste par force brute, crypter toujours deux fois ca revient à doubler la taille de la clef.
A condition d'employer deux fois le même algorithme, ou d'indiquer quels algorithmes ont utilise... En revanche, si je ne dévoile pas l'algorithe utilisé (je ne parle pas de "sécurité par l'obscurité", qui conduit à utiliser des trucs non fiables, plutôt de non-dévoilement d'information), le gars en face est un peu embêté : c'est comme multiplier encore la clef par le nombre d'algorihtmes utilisables, non ?
Non, en cryptographie la règle est claire: l'algorithme de chiffrement est publique.
Si tu connais deux algo de chiffrement, l'algo A qui utilise une clef de q bits et l'algo B qui utilise une clef p bits. Si ton nouveau algo révolutionnaire c'est "crypter avec A puis avec B", alors quelqu'un qui veut faire de la force brute, va générer les 2^p clefs de B et les 2^q clefs de A. Et il devra pour chaque clef de B, tester toutes les clefs A ca fait donc au total 2^p + 2^q = 2^(p+q) tests.
Tout se passe comme si ton algorithme utilise une seule clef de p+q bits.
Mais c'est equivalent si le type ne fait que de la force brute. Il est evident que si tu cryptes deux fois avec RSA avec deux clefs de 64 bits, ce n'est pas pareil qu'avec une clef de 128 bits. Deux petites clefs ca se casse plus facilement qu'une grosse.
Est-ce que les GPG et autres permettent de faire ce genre de trucs ; je veux dire : choisir une séquence d'algos de chiffrages successifs ? (ce qui reviendrait à avoir une "méta-clé" ?)... mfff, je viens de me relire ; ça a pas beaucoup d'intérêt ; autant allonger la clé de base ?
Voilà :)
En tout cas, je pige un peu mieux tout ça, merci beaucoup !
De rien.
-- Marc. Si vous voullez m'envoyer un message chiffré, utilisez ma clef publique: (1007, 35).
Amethyste
On recommande parfois de compresser le fichier a chiffrer (Pkzip ou autre) avant de le chiffrer.
Il existe au moins un livre consacre a la "crypto compression" (celui de X. Marsault)
De cette facon une attaque qui essayerait d'utiliser la connaissance des proprietes du texte clair serait plus difficile.
Encore faut il, bien sur, que le logiciel de compression utilise ne comporte pas une "signature", c'est a dire une suite de caracteres constants :-))
Et accessoirement la compression permet de reduire le volume a transmettre ce qui est toujours appreciable pour diminuer la charge des reseaux ...
On recommande parfois de compresser le fichier a chiffrer (Pkzip ou autre)
avant de le chiffrer.
Il existe au moins un livre consacre a la "crypto compression" (celui de X.
Marsault)
De cette facon une attaque qui essayerait d'utiliser la connaissance des
proprietes du texte
clair serait plus difficile.
Encore faut il, bien sur, que le logiciel de compression utilise ne comporte
pas une "signature",
c'est a dire une suite de caracteres constants :-))
Et accessoirement la compression permet de reduire le volume a transmettre
ce qui est toujours
appreciable pour diminuer la charge des reseaux ...
On recommande parfois de compresser le fichier a chiffrer (Pkzip ou autre) avant de le chiffrer.
Il existe au moins un livre consacre a la "crypto compression" (celui de X. Marsault)
De cette facon une attaque qui essayerait d'utiliser la connaissance des proprietes du texte clair serait plus difficile.
Encore faut il, bien sur, que le logiciel de compression utilise ne comporte pas une "signature", c'est a dire une suite de caracteres constants :-))
Et accessoirement la compression permet de reduire le volume a transmettre ce qui est toujours appreciable pour diminuer la charge des reseaux ...
Je n'y avais pas pensé... Je vais essayer de ce côté là... Merci !
Corto
Jean-Marc Desperrier
Corto wrote:
[Pourquoi compresser avant de signer] De cette facon une attaque qui essayerait d'utiliser la connaissance des proprietes du texte clair serait plus difficile.
Encore faut il, bien sur, que le logiciel de compression utilise ne comporte pas une "signature", c'est a dire une suite de caracteres constants :-)) [...]
Je n'y avais pas pensé... Je vais essayer de ce côté là... Merci !
Cela dit : - un algo qui a une quelconque sensibilité à une attaque par texte clair n'est pas sérieux (l'algo de chiffrement de zip a ce problème, et bien qu'il est justement toujours utilisé avec un contenu chiffré c'est une faille *majeure* en pratique :-) ) - il est un peu difficile d'éviter totalement d'avoir une signature dans le fichier chiffré et je ne crois pas qu'aucun algo de compression standard ait cette propriété.
Corto wrote:
[Pourquoi compresser avant de signer]
De cette facon une attaque qui essayerait d'utiliser la connaissance des
proprietes du texte
clair serait plus difficile.
Encore faut il, bien sur, que le logiciel de compression utilise ne
comporte
pas une "signature",
c'est a dire une suite de caracteres constants :-))
[...]
Je n'y avais pas pensé... Je vais essayer de ce côté là... Merci !
Cela dit :
- un algo qui a une quelconque sensibilité à une attaque par texte clair
n'est pas sérieux (l'algo de chiffrement de zip a ce problème, et bien
qu'il est justement toujours utilisé avec un contenu chiffré c'est une
faille *majeure* en pratique :-) )
- il est un peu difficile d'éviter totalement d'avoir une signature dans
le fichier chiffré et je ne crois pas qu'aucun algo de compression
standard ait cette propriété.
[Pourquoi compresser avant de signer] De cette facon une attaque qui essayerait d'utiliser la connaissance des proprietes du texte clair serait plus difficile.
Encore faut il, bien sur, que le logiciel de compression utilise ne comporte pas une "signature", c'est a dire une suite de caracteres constants :-)) [...]
Je n'y avais pas pensé... Je vais essayer de ce côté là... Merci !
Cela dit : - un algo qui a une quelconque sensibilité à une attaque par texte clair n'est pas sérieux (l'algo de chiffrement de zip a ce problème, et bien qu'il est justement toujours utilisé avec un contenu chiffré c'est une faille *majeure* en pratique :-) ) - il est un peu difficile d'éviter totalement d'avoir une signature dans le fichier chiffré et je ne crois pas qu'aucun algo de compression standard ait cette propriété.
Misterjack
Salut !
ca fait donc au total 2^p + 2^q = 2^(p+q) tests.
Euh... non. 2^2 + 2^2 = 4+4 = 8 = 2^3 et pas 2^4...
Il est evident que si tu cryptes deux fois avec RSA avec deux clefs de 64 bits, ce n'est pas pareil qu'avec une clef de 128 bits. Deux petites clefs ca se casse plus facilement qu'une grosse.
Ce qui montre bien que l'affirmtion précédente était fausse... Et ouais... ça arrive à tout le monde de ne pas dormir assez :D
@Tchao ! -- Mister Jack (MJ) "Linux c'est pas pour les manchots !"
Salut !
ca fait donc au total 2^p + 2^q = 2^(p+q) tests.
Euh... non.
2^2 + 2^2 = 4+4 = 8 = 2^3 et pas 2^4...
Il est evident que si tu cryptes deux fois avec RSA avec deux clefs de
64 bits, ce n'est pas pareil qu'avec une clef de 128 bits. Deux petites
clefs ca se casse plus facilement qu'une grosse.
Ce qui montre bien que l'affirmtion précédente était fausse...
Et ouais... ça arrive à tout le monde de ne pas dormir assez :D
@Tchao !
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Euh... non. 2^2 + 2^2 = 4+4 = 8 = 2^3 et pas 2^4...
Il est evident que si tu cryptes deux fois avec RSA avec deux clefs de 64 bits, ce n'est pas pareil qu'avec une clef de 128 bits. Deux petites clefs ca se casse plus facilement qu'une grosse.
Ce qui montre bien que l'affirmtion précédente était fausse... Et ouais... ça arrive à tout le monde de ne pas dormir assez :D
@Tchao ! -- Mister Jack (MJ) "Linux c'est pas pour les manchots !"
Philippe Gauron
Misterjack répondit:
Salut !
Si ton nouveau algo révolutionnaire c'est "crypter avec A puis avec B", alors quelqu'un qui veut faire de la force brute, va générer les 2^p clefs de B et les 2^q clefs de A. Et il devra pour chaque clef de B, tester toutes les clefs A ca fait donc au total 2^p + 2^q = 2^(p+q) tests.
Euh... non. 2^2 + 2^2 = 4+4 = 8 = 2^3 et pas 2^4...
Il fallait lire 2^p x 2^q = 2^(p+q), ce qui se comprend avec les explication qui étaient au dessus.
Fil.
Misterjack répondit:
Salut !
Si ton nouveau algo révolutionnaire c'est "crypter avec A puis avec
B", alors quelqu'un qui veut faire de la force brute, va générer les
2^p clefs de B et les 2^q clefs de A. Et il devra pour chaque clef de
B, tester toutes les clefs A
ca fait donc au total 2^p + 2^q = 2^(p+q) tests.
Euh... non.
2^2 + 2^2 = 4+4 = 8 = 2^3 et pas 2^4...
Il fallait lire 2^p x 2^q = 2^(p+q), ce qui se comprend avec les
explication qui étaient au dessus.
Si ton nouveau algo révolutionnaire c'est "crypter avec A puis avec B", alors quelqu'un qui veut faire de la force brute, va générer les 2^p clefs de B et les 2^q clefs de A. Et il devra pour chaque clef de B, tester toutes les clefs A ca fait donc au total 2^p + 2^q = 2^(p+q) tests.
Euh... non. 2^2 + 2^2 = 4+4 = 8 = 2^3 et pas 2^4...
Il fallait lire 2^p x 2^q = 2^(p+q), ce qui se comprend avec les explication qui étaient au dessus.
