par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité ou de vitesse de
chiffrement/déchiffrement (ou les deux) ou bien est il considéré comme
très sûr ?
Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité ou de vitesse de
chiffrement/déchiffrement (ou les deux) ou bien est il considéré comme
très sûr ?
Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité ou de vitesse de
chiffrement/déchiffrement (ou les deux) ou bien est il considéré comme
très sûr ?
Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
On Sun Aug 08 2004 at 15:17, Guillaume Kaddouch wrote:par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Il n'est pas cassé, à ma connaissance.Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Oui. Et donc ?Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Blowfish ne manipule que des blocs de 64 bits. Ça peut déplaire aux
paranoïaques.
Pourquoi ne pas choisir AES, maintenant qu'il existe ?Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Raisonnable ? Non, 128 bits sont largement suffisants, et ça vous
évitera de vous prendre le chou avec des considérations légales.
On Sun Aug 08 2004 at 15:17, Guillaume Kaddouch wrote:
par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Il n'est pas cassé, à ma connaissance.
Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Oui. Et donc ?
Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Blowfish ne manipule que des blocs de 64 bits. Ça peut déplaire aux
paranoïaques.
Pourquoi ne pas choisir AES, maintenant qu'il existe ?
Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Raisonnable ? Non, 128 bits sont largement suffisants, et ça vous
évitera de vous prendre le chou avec des considérations légales.
On Sun Aug 08 2004 at 15:17, Guillaume Kaddouch wrote:par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Il n'est pas cassé, à ma connaissance.Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Oui. Et donc ?Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Blowfish ne manipule que des blocs de 64 bits. Ça peut déplaire aux
paranoïaques.
Pourquoi ne pas choisir AES, maintenant qu'il existe ?Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Raisonnable ? Non, 128 bits sont largement suffisants, et ça vous
évitera de vous prendre le chou avec des considérations légales.
Si Open utilise blowfish avec ne fut-ce qu'un petit risque de par son
design... Un petit risque n'est peut-etre pas grand chose pour les
gens normaux mais pas pour OpenBSD.
Si Open utilise blowfish avec ne fut-ce qu'un petit risque de par son
design... Un petit risque n'est peut-etre pas grand chose pour les
gens normaux mais pas pour OpenBSD.
Si Open utilise blowfish avec ne fut-ce qu'un petit risque de par son
design... Un petit risque n'est peut-etre pas grand chose pour les
gens normaux mais pas pour OpenBSD.
On Sun Aug 08 2004 at 15:17, Guillaume Kaddouch wrote:par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Il n'est pas cassé, à ma connaissance.Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Oui. Et donc ?Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Blowfish ne manipule que des blocs de 64 bits. Ça peut déplaire aux
paranoïaques.
Pourquoi ne pas choisir AES, maintenant qu'il existe ?Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Raisonnable ? Non, 128 bits sont largement suffisants, et ça vous
évitera de vous prendre le chou avec des considérations légales.
On Sun Aug 08 2004 at 15:17, Guillaume Kaddouch wrote:
par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Il n'est pas cassé, à ma connaissance.
Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Oui. Et donc ?
Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Blowfish ne manipule que des blocs de 64 bits. Ça peut déplaire aux
paranoïaques.
Pourquoi ne pas choisir AES, maintenant qu'il existe ?
Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Raisonnable ? Non, 128 bits sont largement suffisants, et ça vous
évitera de vous prendre le chou avec des considérations légales.
On Sun Aug 08 2004 at 15:17, Guillaume Kaddouch wrote:par pure curiosité, créant quelques programmes utilisant le
chiffrement dans mon temps libre, je me demandait ce que valait
l'algorithme Blowfish ?
Il n'est pas cassé, à ma connaissance.Cet algorithme accepte des clés juqu'a 448 bits apparemment.
Oui. Et donc ?Ma question plus précisement serait est ce que Blowfish est loin
derrière AES (Rijndael) soit en terme de sécurité
Blowfish ne manipule que des blocs de 64 bits. Ça peut déplaire aux
paranoïaques.
Pourquoi ne pas choisir AES, maintenant qu'il existe ?Une clé de 256bits pour une utilisation personelle semble-t-elle
raisonable ?
Raisonnable ? Non, 128 bits sont largement suffisants, et ça vous
évitera de vous prendre le chou avec des considérations légales.
Intuitivement effectivement je perçois un risque mais y'a t-il une
explication plus rationnelle ;-) de ce problème ?
En gros pourquoi manipuler uniquement des blocs de 64 bits peut-être non
secure ?
Intuitivement effectivement je perçois un risque mais y'a t-il une
explication plus rationnelle ;-) de ce problème ?
En gros pourquoi manipuler uniquement des blocs de 64 bits peut-être non
secure ?
Intuitivement effectivement je perçois un risque mais y'a t-il une
explication plus rationnelle ;-) de ce problème ?
En gros pourquoi manipuler uniquement des blocs de 64 bits peut-être non
secure ?
According to Franck Arnulfo :Intuitivement effectivement je perçois un risque mais y'a t-il une
explication plus rationnelle ;-) de ce problème ?
En gros pourquoi manipuler uniquement des blocs de 64 bits peut-être non
secure ?
Le problème évoqué est que les blocs ne font _que_ 64 bits, et pas 128
comme dans le cas de l'AES.
Prenons le cas du mode de chiffrement OFB avec un feedback d'un bloc
complet. C'est un mode de chiffrement où on utilise l'algorithme
en boucle, avec seulement la clé et sans intervention des données
elles-mêmes, pour générer un flux d'octets pseudo-aléatoires qu'on
combine ensuite avec les données par un XOR bit à bit. Plus précisément,
on part d'une valeur initiale (de la taille d'un bloc) conventionnelle
ou transmise en clair avec le message ; je nomme IV cette valeur.
Du coup, on calcule :
x_0 = E_k(IV) x_0 est le chiffré de IV par la clé k
x_1 = E_k(x_0) x_1 est le chiffré de x_0 par la clé k
x_2 = E_k(x_1) x_2 est le chiffré de x_1 par la clé k
etc...
L'ensemble des x_i, mis bout à bout, forme un flux d'octets
pseudo-aléatoires aussi long qu'on veut. On combine ce flux avec les
données à chiffrer, par XOR. Le déchiffrement est identique (on regénère
le flux et on recombine par XOR). C'est le principe du "one-time pad"
avec le flux pseudo-aléatoire dans le rôle du "pad".
Le problème, c'est que le flux pseudo-aléatoire ne le reste pas si
longtemps que ça. À terme, le système boucle : un des x_i finit par
être égal à un x_j précédent. À partir de là, ça cycle, et le flux
pseudo-aléatoire devient répétitif. Le "one-time pad" devient un
"two-times pad", ce qui n'est pas bon du tout du point de vue sécurité.
Il s'avère que le nombre d'étapes nécessaires pour cycler est en gros
égal à la racine carrée de l'espace sur lequelle on travaille.
blocs font 64 bits, l'espace est de taille 2^64 (le nombre de valeurs
distinctes de 64 bits) et la racine carrée est de 2^32, c'est-à-dire un
peu plus de 4 milliards. En clair, ça veut dire qu'au bout de quelques
dizaines de giga-octets de flux générés, on a de bonnes chances d'avoir
bouclé. Donc, si on chiffre en OFB avec un algorithme de chiffrement
qui a des blocs de 64 bits, on a fortement intérêt à ne pas chiffrer
de message plus long que quelques giga-octets. Même chiffrer un unique
DVD est techniquement un risque. Avec un algorithme comme l'AES qui
travaille sur des blocs de 128 bits, le même problème existe, mais ne
survient qu'après 2^64 blocs de 128 bits, soit un peu moins de 300
millions de téra-octets, ce qui laisse de la marge (pour le moment).
Tout ceci est une illustration du fait que des blocs de 64 bits peuvent
poser des problèmes de sécurité quand on manipule des données par
giga-octets, ce qui commence à devenir courant de nos jours (un réseau
ethernet 100baseT crache son giga-octet en moins de deux minutes ; un
DVD contient facilement sa dizaine de giga-octets de données). Le cas du
mode OFB est un peu extrême, mais pas mal d'autres modes de chiffrement
sont affectés (soit qu'il y ait un problème de sécurité avéré, soit
que l'effet "racine carrée" mette à mal une preuve de sécurité et
donc diminue la confiance qu'on peut placer a priori dans le système
de chiffrement). Aussi, un algorithme avec des blocs de 128 bits est
considéré comme meilleur. C'est pour cela que quand le gouvernement
américain a défini son nouvel algorithme de chiffrement pour remplacer
le DES, il a posé comme condition préalable pour les candidats que
l'algorithme devait travailler avec des blocs de 128 bits.
--Thomas Pornin
According to Franck Arnulfo <no@no.com>:
Intuitivement effectivement je perçois un risque mais y'a t-il une
explication plus rationnelle ;-) de ce problème ?
En gros pourquoi manipuler uniquement des blocs de 64 bits peut-être non
secure ?
Le problème évoqué est que les blocs ne font _que_ 64 bits, et pas 128
comme dans le cas de l'AES.
Prenons le cas du mode de chiffrement OFB avec un feedback d'un bloc
complet. C'est un mode de chiffrement où on utilise l'algorithme
en boucle, avec seulement la clé et sans intervention des données
elles-mêmes, pour générer un flux d'octets pseudo-aléatoires qu'on
combine ensuite avec les données par un XOR bit à bit. Plus précisément,
on part d'une valeur initiale (de la taille d'un bloc) conventionnelle
ou transmise en clair avec le message ; je nomme IV cette valeur.
Du coup, on calcule :
x_0 = E_k(IV) x_0 est le chiffré de IV par la clé k
x_1 = E_k(x_0) x_1 est le chiffré de x_0 par la clé k
x_2 = E_k(x_1) x_2 est le chiffré de x_1 par la clé k
etc...
L'ensemble des x_i, mis bout à bout, forme un flux d'octets
pseudo-aléatoires aussi long qu'on veut. On combine ce flux avec les
données à chiffrer, par XOR. Le déchiffrement est identique (on regénère
le flux et on recombine par XOR). C'est le principe du "one-time pad"
avec le flux pseudo-aléatoire dans le rôle du "pad".
Le problème, c'est que le flux pseudo-aléatoire ne le reste pas si
longtemps que ça. À terme, le système boucle : un des x_i finit par
être égal à un x_j précédent. À partir de là, ça cycle, et le flux
pseudo-aléatoire devient répétitif. Le "one-time pad" devient un
"two-times pad", ce qui n'est pas bon du tout du point de vue sécurité.
Il s'avère que le nombre d'étapes nécessaires pour cycler est en gros
égal à la racine carrée de l'espace sur lequelle on travaille.
blocs font 64 bits, l'espace est de taille 2^64 (le nombre de valeurs
distinctes de 64 bits) et la racine carrée est de 2^32, c'est-à-dire un
peu plus de 4 milliards. En clair, ça veut dire qu'au bout de quelques
dizaines de giga-octets de flux générés, on a de bonnes chances d'avoir
bouclé. Donc, si on chiffre en OFB avec un algorithme de chiffrement
qui a des blocs de 64 bits, on a fortement intérêt à ne pas chiffrer
de message plus long que quelques giga-octets. Même chiffrer un unique
DVD est techniquement un risque. Avec un algorithme comme l'AES qui
travaille sur des blocs de 128 bits, le même problème existe, mais ne
survient qu'après 2^64 blocs de 128 bits, soit un peu moins de 300
millions de téra-octets, ce qui laisse de la marge (pour le moment).
Tout ceci est une illustration du fait que des blocs de 64 bits peuvent
poser des problèmes de sécurité quand on manipule des données par
giga-octets, ce qui commence à devenir courant de nos jours (un réseau
ethernet 100baseT crache son giga-octet en moins de deux minutes ; un
DVD contient facilement sa dizaine de giga-octets de données). Le cas du
mode OFB est un peu extrême, mais pas mal d'autres modes de chiffrement
sont affectés (soit qu'il y ait un problème de sécurité avéré, soit
que l'effet "racine carrée" mette à mal une preuve de sécurité et
donc diminue la confiance qu'on peut placer a priori dans le système
de chiffrement). Aussi, un algorithme avec des blocs de 128 bits est
considéré comme meilleur. C'est pour cela que quand le gouvernement
américain a défini son nouvel algorithme de chiffrement pour remplacer
le DES, il a posé comme condition préalable pour les candidats que
l'algorithme devait travailler avec des blocs de 128 bits.
--Thomas Pornin
According to Franck Arnulfo :Intuitivement effectivement je perçois un risque mais y'a t-il une
explication plus rationnelle ;-) de ce problème ?
En gros pourquoi manipuler uniquement des blocs de 64 bits peut-être non
secure ?
Le problème évoqué est que les blocs ne font _que_ 64 bits, et pas 128
comme dans le cas de l'AES.
Prenons le cas du mode de chiffrement OFB avec un feedback d'un bloc
complet. C'est un mode de chiffrement où on utilise l'algorithme
en boucle, avec seulement la clé et sans intervention des données
elles-mêmes, pour générer un flux d'octets pseudo-aléatoires qu'on
combine ensuite avec les données par un XOR bit à bit. Plus précisément,
on part d'une valeur initiale (de la taille d'un bloc) conventionnelle
ou transmise en clair avec le message ; je nomme IV cette valeur.
Du coup, on calcule :
x_0 = E_k(IV) x_0 est le chiffré de IV par la clé k
x_1 = E_k(x_0) x_1 est le chiffré de x_0 par la clé k
x_2 = E_k(x_1) x_2 est le chiffré de x_1 par la clé k
etc...
L'ensemble des x_i, mis bout à bout, forme un flux d'octets
pseudo-aléatoires aussi long qu'on veut. On combine ce flux avec les
données à chiffrer, par XOR. Le déchiffrement est identique (on regénère
le flux et on recombine par XOR). C'est le principe du "one-time pad"
avec le flux pseudo-aléatoire dans le rôle du "pad".
Le problème, c'est que le flux pseudo-aléatoire ne le reste pas si
longtemps que ça. À terme, le système boucle : un des x_i finit par
être égal à un x_j précédent. À partir de là, ça cycle, et le flux
pseudo-aléatoire devient répétitif. Le "one-time pad" devient un
"two-times pad", ce qui n'est pas bon du tout du point de vue sécurité.
Il s'avère que le nombre d'étapes nécessaires pour cycler est en gros
égal à la racine carrée de l'espace sur lequelle on travaille.
blocs font 64 bits, l'espace est de taille 2^64 (le nombre de valeurs
distinctes de 64 bits) et la racine carrée est de 2^32, c'est-à-dire un
peu plus de 4 milliards. En clair, ça veut dire qu'au bout de quelques
dizaines de giga-octets de flux générés, on a de bonnes chances d'avoir
bouclé. Donc, si on chiffre en OFB avec un algorithme de chiffrement
qui a des blocs de 64 bits, on a fortement intérêt à ne pas chiffrer
de message plus long que quelques giga-octets. Même chiffrer un unique
DVD est techniquement un risque. Avec un algorithme comme l'AES qui
travaille sur des blocs de 128 bits, le même problème existe, mais ne
survient qu'après 2^64 blocs de 128 bits, soit un peu moins de 300
millions de téra-octets, ce qui laisse de la marge (pour le moment).
Tout ceci est une illustration du fait que des blocs de 64 bits peuvent
poser des problèmes de sécurité quand on manipule des données par
giga-octets, ce qui commence à devenir courant de nos jours (un réseau
ethernet 100baseT crache son giga-octet en moins de deux minutes ; un
DVD contient facilement sa dizaine de giga-octets de données). Le cas du
mode OFB est un peu extrême, mais pas mal d'autres modes de chiffrement
sont affectés (soit qu'il y ait un problème de sécurité avéré, soit
que l'effet "racine carrée" mette à mal une preuve de sécurité et
donc diminue la confiance qu'on peut placer a priori dans le système
de chiffrement). Aussi, un algorithme avec des blocs de 128 bits est
considéré comme meilleur. C'est pour cela que quand le gouvernement
américain a défini son nouvel algorithme de chiffrement pour remplacer
le DES, il a posé comme condition préalable pour les candidats que
l'algorithme devait travailler avec des blocs de 128 bits.
--Thomas Pornin
Ce n'est pas tout à fait exact (en tout cas de manière générale) !
Cela dépend de l'estimation du nombre d'états inversibles par la
fonction f. En effet, si par exemple tous les états sont inversibles,
alors le nombre d'itérations moyens avant de boucler, correspond au
nombre d'itérations moyen requis avant de tomber sur l'inverse de l'état
initial, c'est à dire 2^63 et non plus 2^32.
Ce n'est pas tout à fait exact (en tout cas de manière générale) !
Cela dépend de l'estimation du nombre d'états inversibles par la
fonction f. En effet, si par exemple tous les états sont inversibles,
alors le nombre d'itérations moyens avant de boucler, correspond au
nombre d'itérations moyen requis avant de tomber sur l'inverse de l'état
initial, c'est à dire 2^63 et non plus 2^32.
Ce n'est pas tout à fait exact (en tout cas de manière générale) !
Cela dépend de l'estimation du nombre d'états inversibles par la
fonction f. En effet, si par exemple tous les états sont inversibles,
alors le nombre d'itérations moyens avant de boucler, correspond au
nombre d'itérations moyen requis avant de tomber sur l'inverse de l'état
initial, c'est à dire 2^63 et non plus 2^32.
