CRYPTOGRAPHIE PAR ENCAPSULATION DANS UN NOMBRE ALEATOIRE - C.E.N.A
20 réponses
Philippe Lheureux
CRYPTOGRAPHIE
PAR
ENCAPSULATION
DANS UN NOMBRE
ALEATOIRE
(C.E.N.A)
Une idée de Philippe Lheureux
L’idée de base est de produire un chiffre insensible à toute autre attaque
que celle à la force brute.
Principe de base.
Grâce à une première clé utilisant des intervalles de longueurs variables,
chaque caractère ascii à chiffrer est chiffrable avec plus de 3000 valeurs
différentes comportant 6 chiffres.
Grace une deuxième clé variable en longueur, les 6 chiffres du nombre
extrait de l’intervalle sont ensuite mélangés puis incorporés chiffre par
chiffre à l’intérieur d’un nombre aléatoire de 16 chiffres.
A chaque caractère chiffré, la première clé et la deuxième clé sont soumises
à une évolution pour assurer l’invulnérabilité du chiffre produit.
Principe de fonctionnement.
1 – Création d’une première partie de clé
L’intervalle général de travail à prendre en compte se situe entre 100000 et
999999 compris. Ce qui fait 999999-100000=899999 possibilités d’utiliser un
chiffre compris entre 100000 et 999999 pour coder l’ensemble des 256
caractères ASCII.
La moyenne par caractères ASCII est donc de 899999/256 =3515.62
possibilités de chiffrage différents.
Le premier but à atteindre est la création d’un tableau à deux dimensions
faisant coïncider chacun des caractères ASCII avec un intervalle bien
précis.
Afin de compliquer la cryptanalyse, les intervalles doivent être variables
et les cases du tableau des caractères ASCII remplis avec un ordre
ALEATOIRE.
La variabilité d’un intervalle est de 515 numéros.
Remplir le tableau de 0 a 255 avec un algorithme fixant la valeur BORN_MAX
de chaque intervalle.
La valeur de départ étant : 100000
BORN_MAX(0)= 100000 + 3000 + (un chiffre pris au hasard entre 0 et 515)
BORN_MAX(1)= BORN_MAX(0) + 3000 + (un chiffre pris au hasard entre 0 et 515)
Et ainsi de suite
Jusqu'à BORN_MAX(254)
La 256 eme case du tableau (qui va de l’indice 0 à l’indice 255) contiendra
donc plus de 3515 possibilités de chiffrage.
BORN_MAX(255)= forcement 999999
En ce qui concerne la répartition des caractères ASCII affectés à chaque
intervalle, il faut aussi que les cases soient remplies au hasard
Exemple :
CARACTERE(0)=195 (195 est le code du caractère ASCII )
CARACTERE(1)=62
CARACTERE(2)=69
CARACTERE(3)=47
Et ainsi de suite jusqu'à ce que les 256 cases soient remplies avec des
valeurs différentes.
Pour remplir le tableau de manière aléatoire, utilisez la méthode qui vous
semblera la plus appropriée.
En général on fait deux boucles, une avance dans l’indice du tableau et l’autre
sélectionne aléatoirement un numéro qui n’a pas déjà été pris précédemment.
Dans notre exemple, le caractère ASCII 195 pourra être écrit de
BORN_MAX(0) -100000 manières différentes.
Une fois le tableau crée, n’importe quel caractère ASCII pourra être chiffré
par une des valeurs prise au hasard entre les BORN_MAX .
Admettons que le caractère B corresponde à un indice du tableau situé entre
258967 et 262367, tous les chiffres compris entre 258697 et 262367-1
pourront servir pour le chiffrer.
2- Brouillage du numéro extrait de l’intervalle.
Le numéro à 6 chiffres (extrait le plus possible au hasard dans l’intervalle
des 3000 numéros minimum possibles correspondants au caractère ASCII à
chiffrer) va maintenant subir une série de transformations destinées a
brouiller les pistes.
Le principe de base consiste à mélanger l’ordre des 6 chiffres extraits puis
d’incorporer ceux-ci dans un numéro aléatoire composé de 16 chiffres.
Exemple de transformation du numéro 548973
A : Création d’une clé de 16 caractères montrant l’ordre et la position de
la séquence de chiffres du numéro extrait a l’intérieur d’un numéro
aléatoire
XX5XX43XX6X1XX2X
Les X sont destinés à être remplacés par des chiffres aléatoires entre 0 et
9
1 correspond a la position du 1 er chiffre du numéro extrait (5)
2 correspond a la position du 2 ème chiffre du numéro extrait (4)
3 correspond a la position du 3 ème chiffre du numéro extrait (8)
4 correspond a la position du 4 ème chiffre du numéro extrait (9)
5 correspond a la position du 5 ème chiffre du numéro extrait (7)
6 correspond a la position du 6 ème chiffre du numéro extrait (3)
B : incorporation
XX5XX43XX6X1XX2X
Devient donc après injection des chiffres du numéro extrait
XX7XX98XX3X5XX4X
C : masquage aléatoire
Puis
4770698113450747
Ou
1578198473950040
En remplaçant les X par de l’aléatoire. Bien entendu, celui qui a la clé
pourra facilement extraire puis remettre en ordre les chiffres du numéro
extrait dans l’intervalle.
Sans la clé, XX5XX43XX6X1XX2X l’opération s’avère délicate
Cette clé sera bien sur rajoutée a la clé 1 contenant la position des
caractères ASCII et les intervalles.
A ce stade, il reste encore une petite faiblesse liée au fait que compte
tenu des numéros extraits dans les intervalles, presque 3 ou 4 chiffres sur
6 restent identiques pour un même caractère chiffré en continu. Même
incorporés dans de l’aléatoire, on pourrait finir par les repérer
statistiquement. Cela ne donnerait pas l’ordre pour autant mais autant ne
laisser aucune trace exploitable.
3 – Masquage définitif
Afin d’éviter de pouvoir repérer les 3 ou 4 chiffres qui restent identiques
à chaque même caractère chiffré, il suffit d’appliquer deux principes
complémentaires.
A : Premier principe
A chaque caractère chiffré, il faut décaler le tableau de base pour que le
caractère qui vient d’être chiffré saute d’un intervalle.
Au bout de 256 caractères, il revient en position d’origine.
Le but est de faire en sorte que les premiers chiffres des numéros extraits
dans les intervalles varient constamment.
Ceci dit, on pourrait encore repérer statistiquement cet accroissement
progressif de certains numéros
B : Deuxième principe
Au lieu de générer une simple clé de 16 caractères gérant l’ordre et la
position des chiffres incorporés, on va fabriquer une clé de X fois 16
caractères
X en fonction du degré de sécurité choisi.
Admettons que vous mettiez X à 21, cela créera une clé comportant 21
séquences différentes de 16 positions + ordre.
Le premier caractère chiffré utilise la clé 1, le deuxième la clé 2, le 21
ème , la clé 21 et le 22 ème , la clé 1
C’est ce changement de clé permanent associé au décalage de la table qui va
engendrer la sécurité du chiffre produit.
La clé finale se composera donc de la table associant caractères ASCII avec
intervalles + x fois la clé d’ordre et de position permettant l’extraction
de ce qui a été incorporé dans l’aléatoire.
Votre avis concernant les attaques possibles sur ce genre de chiffre sont
les bienvenues.
Est ce compressible au final ?
Si c'était un "nombre", je proposerais bien 1 << 256 ?...
-- christophe. [Une autre notation est possible, mé c'est pas moi qui ai commencé]
Philippe Lheureux
Bonjour Stéphane,
Ce qui me fait marrer, c'est que ta phrase résume que tu n'as toujours rien compris à ce qui t'était reproché et que tu en es fier. Tu enfumes, mais tu ne sécurises pas. Lorsque quelqu'un te montre que ton algo est troué, tu obscurcis, mais tu ne le rends pas plus sûr.
Pour l'instant , personne n'a montré une seule faille à cet algo.
Si tu vois qu'une porte a une serrure faible, rajouter du chatterton sur ta serrure la cachera. Ça compliquera un peu la tâche de celui qui veut crocheter la serrure, mais ça ne rend pas la serrure plus solide. La personne qui veut entrer enlèverra le chatterton. Et toi, tu vas alors mettre deux bouts de chatterton. Les gens d'ici vont enlever les deux bouts de chatterton et toi, tu vas en rajouter un troisième.
J'ai justement promis de ne rien toucher , le pseudo code CENA est publié en tête de Thread et il restera tel qu'il est.
Une fois que tu auras mis quinze bouts de chatterton, les plus tenaces vont abandonner parce que ça ne sert à rien et que c'est chiant au bout d'un moment. Comme tu n'auras rien compris à la raison pour laquelle ils laissent tomber, tu vas fanfaronner en disant que quinze bouts de chatterton sécurisent une serrure.
Non , j'ai dis dès le départ que je ne modifierais rien de CENA et que si une attaque démontre sa faiblesse , il est foutu.
Mais c'est faux. Une pléthore de faux signaux parasites ne sécurise rien du tout. Ça complexifie la tâche de l'attaquant, ce qui n'est pas un mal si ce que tu embrouilles est performant. Mais c'est inutile si tu embrouilles quelque chose de faible.
J'aimerais bien savoir comment tu t'y prendrais pour attaquer CENA :-) ou est la faiblesse imaginée ? Si tu l'étudies un peu , je pense que tu verras que c'est beaucoup plus solide que tu l'imagines.
Bonjour Stéphane,
Ce qui me fait marrer, c'est que ta phrase résume que tu n'as toujours
rien
compris à ce qui t'était reproché et que tu en es fier. Tu enfumes, mais
tu
ne sécurises pas. Lorsque quelqu'un te montre que ton algo est troué, tu
obscurcis, mais tu ne le rends pas plus sûr.
Pour l'instant , personne n'a montré une seule faille à cet algo.
Si tu vois qu'une porte a une serrure faible, rajouter du chatterton sur
ta
serrure la cachera. Ça compliquera un peu la tâche de celui qui veut
crocheter la serrure, mais ça ne rend pas la serrure plus solide. La
personne qui veut entrer enlèverra le chatterton. Et toi, tu vas alors
mettre deux bouts de chatterton. Les gens d'ici vont enlever les deux
bouts
de chatterton et toi, tu vas en rajouter un troisième.
J'ai justement promis de ne rien toucher , le pseudo code CENA est publié en
tête de Thread et il restera tel qu'il est.
Une fois que tu auras mis quinze bouts de chatterton, les plus tenaces
vont
abandonner parce que ça ne sert à rien et que c'est chiant au bout d'un
moment. Comme tu n'auras rien compris à la raison pour laquelle ils
laissent
tomber, tu vas fanfaronner en disant que quinze bouts de chatterton
sécurisent une serrure.
Non , j'ai dis dès le départ que je ne modifierais rien de CENA et que si
une attaque démontre sa faiblesse , il est foutu.
Mais c'est faux. Une pléthore de faux signaux parasites ne sécurise rien
du
tout. Ça complexifie la tâche de l'attaquant, ce qui n'est pas un mal si
ce
que tu embrouilles est performant. Mais c'est inutile si tu embrouilles
quelque chose de faible.
J'aimerais bien savoir comment tu t'y prendrais pour attaquer CENA :-) ou
est la faiblesse imaginée ? Si tu l'étudies un peu , je pense que tu verras
que c'est beaucoup plus solide que tu l'imagines.
Ce qui me fait marrer, c'est que ta phrase résume que tu n'as toujours rien compris à ce qui t'était reproché et que tu en es fier. Tu enfumes, mais tu ne sécurises pas. Lorsque quelqu'un te montre que ton algo est troué, tu obscurcis, mais tu ne le rends pas plus sûr.
Pour l'instant , personne n'a montré une seule faille à cet algo.
Si tu vois qu'une porte a une serrure faible, rajouter du chatterton sur ta serrure la cachera. Ça compliquera un peu la tâche de celui qui veut crocheter la serrure, mais ça ne rend pas la serrure plus solide. La personne qui veut entrer enlèverra le chatterton. Et toi, tu vas alors mettre deux bouts de chatterton. Les gens d'ici vont enlever les deux bouts de chatterton et toi, tu vas en rajouter un troisième.
J'ai justement promis de ne rien toucher , le pseudo code CENA est publié en tête de Thread et il restera tel qu'il est.
Une fois que tu auras mis quinze bouts de chatterton, les plus tenaces vont abandonner parce que ça ne sert à rien et que c'est chiant au bout d'un moment. Comme tu n'auras rien compris à la raison pour laquelle ils laissent tomber, tu vas fanfaronner en disant que quinze bouts de chatterton sécurisent une serrure.
Non , j'ai dis dès le départ que je ne modifierais rien de CENA et que si une attaque démontre sa faiblesse , il est foutu.
Mais c'est faux. Une pléthore de faux signaux parasites ne sécurise rien du tout. Ça complexifie la tâche de l'attaquant, ce qui n'est pas un mal si ce que tu embrouilles est performant. Mais c'est inutile si tu embrouilles quelque chose de faible.
J'aimerais bien savoir comment tu t'y prendrais pour attaquer CENA :-) ou est la faiblesse imaginée ? Si tu l'étudies un peu , je pense que tu verras que c'est beaucoup plus solide que tu l'imagines.
xtof pernod
Le 02/09/2010 18:40, c'est pas pour cafter, mais Philippe Lheureux a fait rien qu'à écrire:
Bonjour Stéphane,
Ce qui me fait marrer, c'est que ta phrase résume que tu n'as toujours rien compris à ce qui t'était reproché et que tu en es fier. Tu enfumes, mais tu ne sécurises pas. Lorsque quelqu'un te montre que ton algo est troué, tu obscurcis, mais tu ne le rends pas plus sûr.
Pour l'instant , personne n'a montré une seule faille à cet algo.
s/montré une seule faille à/testé/ (Pour autant que je sache..)
-- christophe.
Le 02/09/2010 18:40, c'est pas pour cafter, mais Philippe Lheureux a fait rien
qu'à écrire:
Bonjour Stéphane,
Ce qui me fait marrer, c'est que ta phrase résume que tu n'as toujours
rien
compris à ce qui t'était reproché et que tu en es fier. Tu enfumes,
mais tu
ne sécurises pas. Lorsque quelqu'un te montre que ton algo est troué, tu
obscurcis, mais tu ne le rends pas plus sûr.
Pour l'instant , personne n'a montré une seule faille à cet algo.
s/montré une seule faille à/testé/
(Pour autant que je sache..)
Le 02/09/2010 18:40, c'est pas pour cafter, mais Philippe Lheureux a fait rien qu'à écrire:
Bonjour Stéphane,
Ce qui me fait marrer, c'est que ta phrase résume que tu n'as toujours rien compris à ce qui t'était reproché et que tu en es fier. Tu enfumes, mais tu ne sécurises pas. Lorsque quelqu'un te montre que ton algo est troué, tu obscurcis, mais tu ne le rends pas plus sûr.
Pour l'instant , personne n'a montré une seule faille à cet algo.
s/montré une seule faille à/testé/ (Pour autant que je sache..)
Oui , c'est exactement le genre de cote qu'on obtiendrait avec mon princi pe de crypto CENA .. pourquoi cette question ?
Priceless, comme on dit en anglais...
Simplement parce qu'il y a des tas d'algorithmes de chiffrement, quit produisent des bits virtuellement impossibles à distinguer d'un flux aléatoire (a comparer à des chaines de nombres ou "il reste quelques petites faiblesses"), où tous les bits sont utiles, qui ne gonflent pas la taille du message initial, qui fonctionnent, au bas mot, des centaines de fois plus vite que ta recette de cuisine, qui sont parfaitement documentés et analysés par des centaines de pros et pour lesquels un "crack" revient à comparer des nombres de 78 chiffres entre eux (par analogie à tes comparaisons de "numéros" de 16 chiffres.
Je pensais que tu en étais conscient, après tes nombreuses lectures sur Internet, et que tu reconnaitrais immédiatement, comme l'a fait xtof pernod, la nature du "numéro".
La crypto selon Philou, c'est
"Je frappe au numéro 1, je d'mande mamzelle Angèle..."
On 2 sep, 18:33, "Philippe Lheureux" <lheureu...@wanadoo.fr> wrote:
Oui , c'est exactement le genre de cote qu'on obtiendrait avec mon princi pe
de crypto CENA .. pourquoi cette question ?
Priceless, comme on dit en anglais...
Simplement parce qu'il y a des tas d'algorithmes de chiffrement, quit
produisent des bits virtuellement impossibles à distinguer d'un flux
aléatoire (a comparer à des chaines de nombres ou "il reste quelques
petites faiblesses"), où tous les bits sont utiles, qui ne gonflent
pas la taille du message initial, qui fonctionnent, au bas mot, des
centaines de fois plus vite que ta recette de cuisine, qui sont
parfaitement documentés et analysés par des centaines de pros et pour
lesquels un "crack" revient à comparer des nombres de 78 chiffres
entre eux (par analogie à tes comparaisons de "numéros" de 16
chiffres.
Je pensais que tu en étais conscient, après tes nombreuses lectures
sur Internet, et que tu reconnaitrais immédiatement, comme l'a fait
xtof pernod, la nature du "numéro".
La crypto selon Philou, c'est
"Je frappe au numéro 1, je d'mande mamzelle Angèle..."
Oui , c'est exactement le genre de cote qu'on obtiendrait avec mon princi pe de crypto CENA .. pourquoi cette question ?
Priceless, comme on dit en anglais...
Simplement parce qu'il y a des tas d'algorithmes de chiffrement, quit produisent des bits virtuellement impossibles à distinguer d'un flux aléatoire (a comparer à des chaines de nombres ou "il reste quelques petites faiblesses"), où tous les bits sont utiles, qui ne gonflent pas la taille du message initial, qui fonctionnent, au bas mot, des centaines de fois plus vite que ta recette de cuisine, qui sont parfaitement documentés et analysés par des centaines de pros et pour lesquels un "crack" revient à comparer des nombres de 78 chiffres entre eux (par analogie à tes comparaisons de "numéros" de 16 chiffres.
Je pensais que tu en étais conscient, après tes nombreuses lectures sur Internet, et que tu reconnaitrais immédiatement, comme l'a fait xtof pernod, la nature du "numéro".
La crypto selon Philou, c'est
"Je frappe au numéro 1, je d'mande mamzelle Angèle..."
Philippe Lheureux
Priceless, comme on dit en anglais...
Simplement parce qu'il y a des tas d'algorithmes de chiffrement, quit produisent des bits virtuellement impossibles à distinguer d'un flux aléatoire (a comparer à des chaines de nombres ou "il reste quelques petites faiblesses"), où tous les bits sont utiles, qui ne gonflent pas la taille du message initial, qui fonctionnent, au bas mot, des centaines de fois plus vite que ta recette de cuisine, qui sont parfaitement documentés et analysés par des centaines de pros et pour lesquels un "crack" revient à comparer des nombres de 78 chiffres entre eux (par analogie à tes comparaisons de "numéros" de 16 chiffres.
tu peux me donner le nom d'un de ces algorithmes ? Ils utilisent surement des formules mathématiques hyper complexes pour arriver a leur fins , c'est surement plus compliqué que mon algo mais moi je suis sur qu'au final ce n'est pas plus sur. D'accord , le mien fait surement gonfler la taille du message mais ce faisant , il gêne considérablement la cryptanalyse en créant des confusions entre chiffres utiles et chiffres inutiles.
Je pensais que tu en étais conscient, après tes nombreuses lectures sur Internet, et que tu reconnaitrais immédiatement, comme l'a fait xtof pernod, la nature du "numéro".
La crypto selon Philou, c'est
"Je frappe au numéro 1, je d'mande mamzelle Angèle..."
Et selon Pierre , circulez y'a mieux ailleurs.
Priceless, comme on dit en anglais...
Simplement parce qu'il y a des tas d'algorithmes de chiffrement, quit
produisent des bits virtuellement impossibles à distinguer d'un flux
aléatoire (a comparer à des chaines de nombres ou "il reste quelques
petites faiblesses"), où tous les bits sont utiles, qui ne gonflent
pas la taille du message initial, qui fonctionnent, au bas mot, des
centaines de fois plus vite que ta recette de cuisine, qui sont
parfaitement documentés et analysés par des centaines de pros et pour
lesquels un "crack" revient à comparer des nombres de 78 chiffres
entre eux (par analogie à tes comparaisons de "numéros" de 16
chiffres.
tu peux me donner le nom d'un de ces algorithmes ? Ils utilisent surement
des formules mathématiques hyper complexes pour arriver a leur fins , c'est
surement plus compliqué que mon algo mais moi je suis sur qu'au final ce
n'est pas plus sur. D'accord , le mien fait surement gonfler la taille du
message mais ce faisant , il gêne considérablement la cryptanalyse en créant
des confusions entre chiffres utiles et chiffres inutiles.
Je pensais que tu en étais conscient, après tes nombreuses lectures
sur Internet, et que tu reconnaitrais immédiatement, comme l'a fait
xtof pernod, la nature du "numéro".
La crypto selon Philou, c'est
"Je frappe au numéro 1, je d'mande mamzelle Angèle..."
Simplement parce qu'il y a des tas d'algorithmes de chiffrement, quit produisent des bits virtuellement impossibles à distinguer d'un flux aléatoire (a comparer à des chaines de nombres ou "il reste quelques petites faiblesses"), où tous les bits sont utiles, qui ne gonflent pas la taille du message initial, qui fonctionnent, au bas mot, des centaines de fois plus vite que ta recette de cuisine, qui sont parfaitement documentés et analysés par des centaines de pros et pour lesquels un "crack" revient à comparer des nombres de 78 chiffres entre eux (par analogie à tes comparaisons de "numéros" de 16 chiffres.
tu peux me donner le nom d'un de ces algorithmes ? Ils utilisent surement des formules mathématiques hyper complexes pour arriver a leur fins , c'est surement plus compliqué que mon algo mais moi je suis sur qu'au final ce n'est pas plus sur. D'accord , le mien fait surement gonfler la taille du message mais ce faisant , il gêne considérablement la cryptanalyse en créant des confusions entre chiffres utiles et chiffres inutiles.
Je pensais que tu en étais conscient, après tes nombreuses lectures sur Internet, et que tu reconnaitrais immédiatement, comme l'a fait xtof pernod, la nature du "numéro".
La crypto selon Philou, c'est
"Je frappe au numéro 1, je d'mande mamzelle Angèle..."
Et selon Pierre , circulez y'a mieux ailleurs.
Philippe Lheureux
Pour l'instant , personne n'a montré une seule faille à cet algo.
s/montré une seule faille à/testé/ (Pour autant que je sache..)
-- christophe.
s/toi parler/comme/ca/m pas /comprendre
Pour l'instant , personne n'a montré une seule faille à cet algo.
s/montré une seule faille à/testé/
(Pour autant que je sache..)
Pour l'instant , personne n'a montré une seule faille à cet algo.
s/montré une seule faille à/testé/ (Pour autant que je sache..)
-- christophe.
s/toi parler/comme/ca/m pas /comprendre
Pierre Vandevenne
On 2 sep, 22:45, "Philippe Lheureux" wrote:
> lesquels un "crack" revient à comparer des nombres de 78 chiffres > entre eux (par analogie à tes comparaisons de "numéros" de 16 > chiffres.
tu peux me donner le nom d'un de ces algorithmes ? Ils utilisent surem ent
Eh bien tous les algorithmes qui utilisent des clés de 256 bits, comme l'AES par example.
des formules mathématiques hyper complexes pour arriver a leur fins , c 'est
Non, c'est assez simple comme "formule". C'est d'ailleurs pour cette raison que la performance est incroyablement plus élévée que sur ton genre de recette. C'est le concept qui est plus complexe, et encore, c'est relativement simple comparé aux courbes elliptiques.
surement plus compliqué que mon algo mais moi je suis sur qu'au final c e n'est pas plus sur.
Meilleure estimation pour ton algorithme, selon toi, comparaison de nombres de 16 chiffres.
Meilleure estimation, sur les mêmes bases que toi pour l'AES 256 bits, comparaison de nombres de 78 chiffres.
Tu as une idée de ce que cela représente.
(en fait il y a probablement un peu miuex contre l'AES
D'accord , le mien fait surement gonfler la taille du message mais ce faisant , il gêne considérablement la cryptanalyse en créant des confusions entre chiffres utiles et chiffres inutiles.
Non, il ne la gêne pas vraiment. Sauf si le message est court, la clé effective longue et qu'elle n'est utilisée qu'une fois (dans ce cas on tend vers une implémentaion hyper tarabiscotée de l'OTP)
Et selon Pierre , circulez y'a mieux ailleurs.
Non, c'est "rarement vu pire".
On 2 sep, 22:45, "Philippe Lheureux" <lheureu...@wanadoo.fr> wrote:
> lesquels un "crack" revient à comparer des nombres de 78 chiffres
> entre eux (par analogie à tes comparaisons de "numéros" de 16
> chiffres.
tu peux me donner le nom d'un de ces algorithmes ? Ils utilisent surem ent
Eh bien tous les algorithmes qui utilisent des clés de 256 bits, comme
l'AES par example.
des formules mathématiques hyper complexes pour arriver a leur fins , c 'est
Non, c'est assez simple comme "formule". C'est d'ailleurs pour cette
raison que la performance est incroyablement plus élévée que sur ton
genre de recette. C'est le concept qui est plus complexe, et encore,
c'est relativement simple comparé aux courbes elliptiques.
surement plus compliqué que mon algo mais moi je suis sur qu'au final c e
n'est pas plus sur.
Meilleure estimation pour ton algorithme, selon toi, comparaison de
nombres de 16 chiffres.
Meilleure estimation, sur les mêmes bases que toi pour l'AES 256 bits,
comparaison de nombres de 78 chiffres.
Tu as une idée de ce que cela représente.
(en fait il y a probablement un peu miuex contre l'AES
D'accord , le mien fait surement gonfler la taille du
message mais ce faisant , il gêne considérablement la cryptanalyse en créant
des confusions entre chiffres utiles et chiffres inutiles.
Non, il ne la gêne pas vraiment. Sauf si le message est court, la clé
effective longue et qu'elle n'est utilisée qu'une fois (dans ce cas on
tend vers une implémentaion hyper tarabiscotée de l'OTP)
> lesquels un "crack" revient à comparer des nombres de 78 chiffres > entre eux (par analogie à tes comparaisons de "numéros" de 16 > chiffres.
tu peux me donner le nom d'un de ces algorithmes ? Ils utilisent surem ent
Eh bien tous les algorithmes qui utilisent des clés de 256 bits, comme l'AES par example.
des formules mathématiques hyper complexes pour arriver a leur fins , c 'est
Non, c'est assez simple comme "formule". C'est d'ailleurs pour cette raison que la performance est incroyablement plus élévée que sur ton genre de recette. C'est le concept qui est plus complexe, et encore, c'est relativement simple comparé aux courbes elliptiques.
surement plus compliqué que mon algo mais moi je suis sur qu'au final c e n'est pas plus sur.
Meilleure estimation pour ton algorithme, selon toi, comparaison de nombres de 16 chiffres.
Meilleure estimation, sur les mêmes bases que toi pour l'AES 256 bits, comparaison de nombres de 78 chiffres.
Tu as une idée de ce que cela représente.
(en fait il y a probablement un peu miuex contre l'AES
D'accord , le mien fait surement gonfler la taille du message mais ce faisant , il gêne considérablement la cryptanalyse en créant des confusions entre chiffres utiles et chiffres inutiles.
Non, il ne la gêne pas vraiment. Sauf si le message est court, la clé effective longue et qu'elle n'est utilisée qu'une fois (dans ce cas on tend vers une implémentaion hyper tarabiscotée de l'OTP)
