Pourquoi de l'AES partout (notamment WPA2) ?

Erwann ABALEA

19/10/2006 à 19:02

Bonjour,

Hodie XIV Kal. Nov. MMVI est, Olivier Masson scripsit:

un peu partout, AES s'impose. C'est la grande mode de WPA2 avec son AES-CCMP.

C'est normal, c'est son but, c'est un standard.

Pourtant AES est bien plus lent que RC4. Alors y'a t'il une raison valable, si l'on ne souhaite
pas chiffrer des infos classées Très Secret Défense, d'utiliser AES plutôt que RC4 ?

RC4 est attirant pour ses performances, mais il est difficile de
l'utiliser de façon sûre, il y a de gros écueils possibles, qui
nuisent complètement à sa sécurité. De plus, RC4 en tant que tel (cette
dénomination) est un secret industriel, on ne connait réellement
qu'ARC4 (Alleged RC4, qui ne signifie pas "allégé", mais "supposé").

Pour répondre à vos questions:
- oui, Rijndael (l'AES) est bien plus lent que RC4, mais il a été
pensé pour être optimisé sur différentes architectures, allant de
la carte à puce 8 bits aux processeurs 64 bits, et c'est le plus
rapide des finalistes au concours AES; de plus, il n'est pas si
lent dans l'absolu, mon poste de dev (P4 3GHz) chiffre en AES des
blocs de 256 octets à la vitesse de 110Mo/s, donc bien plus vite
que le débit de mes disques durs, ou de ma carte réseau,
- on demande tout d'abord à une solution de chiffrement d'être
robuste, avant d'être rapide (sinon, on fait un xor avec un octet
constant), et de ce point de vue, l'AES est bien plus robuste que
RC4.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
That's not a bug, that's a feature.

Olivier Masson

20/10/2006 à 10:57

Pour répondre à vos questions:
- oui, Rijndael (l'AES) est bien plus lent que RC4, mais il a été
pensé pour être optimisé sur différentes architectures, allant de
la carte à puce 8 bits aux processeurs 64 bits, et c'est le plus
rapide des finalistes au concours AES; de plus, il n'est pas si
lent dans l'absolu, mon poste de dev (P4 3GHz) chiffre en AES des
blocs de 256 octets à la vitesse de 110Mo/s, donc bien plus vite
que le débit de mes disques durs, ou de ma carte réseau,
- on demande tout d'abord à une solution de chiffrement d'être
robuste, avant d'être rapide (sinon, on fait un xor avec un octet
constant), et de ce point de vue, l'AES est bien plus robuste que
RC4.

Ok. Merci. J'ignorais qu'il y avait des problèmes de sécurité avec
(A)RC4. La librairie MSARC4 pose un problème ?

Pour la rapidité, tout ceci est bien relatif car j'imagine que cela
dépend du flux à traiter.
En ce qui me concerne, mon problème est le chiffrement de sessions à
distance (type VNC) (sans l'utilisation de tunnel car la mise en place
doit être immédiate et très simple et en plus - plutôt en moins :) -
uniquement sur Windows). Le chiffrement doit être aussi "temps réel" que
possible.
Egalement le chiffrement de données pour un backup distant. Pour
quelques dizaines de Mo, on s'en fout, mais pour quelques dizaines de
Go, passer de RC4 à
Je me pose également la question quant à la diminution de débit et
l'augmentation de charge processeur pour du wifi domestique (donc
utilisant des chipset pas du tout optimisés pour du WPA ou WPA2).
Pour finir,

Je comprends que l'on demande à un solution de chiffrement d'être
surtout robuste, et je pensais que RC4 l'était largement "assez". Mais,
comme son nom d'indique, AES a été fait pour qu'on propose du
chiffrement avancé. Ai-je besoin d'autant que cela, je ne sais pas, mais
je souhaite avant tout la plus grande rapidité possible.

Si on me dit que le chiffrement peut être cassé en brute par une grappe
de 1000 UC en quelques heures, c'est pas trop grave. Si on me dit qu'il
peut être cassée à cause d'un attracteur étrange sur la clé elliptique
de l'espace ultra-dimensionnel en matrice active ( :D j'adore dire
n'importe quoi, ça me rappelle Gotlieb) en 5 heures, ça me gêne
davantage. Donc exit XOR et les algo de Lheureux ;)

Pour répondre à vos questions:
- oui, Rijndael (l'AES) est bien plus lent que RC4, mais il a été
pensé pour être optimisé sur différentes architectures, allant de
la carte à puce 8 bits aux processeurs 64 bits, et c'est le plus
rapide des finalistes au concours AES; de plus, il n'est pas si
lent dans l'absolu, mon poste de dev (P4 3GHz) chiffre en AES des
blocs de 256 octets à la vitesse de 110Mo/s, donc bien plus vite
que le débit de mes disques durs, ou de ma carte réseau,
- on demande tout d'abord à une solution de chiffrement d'être
robuste, avant d'être rapide (sinon, on fait un xor avec un octet
constant), et de ce point de vue, l'AES est bien plus robuste que
RC4.

Ok. Merci. J'ignorais qu'il y avait des problèmes de sécurité avec
(A)RC4. La librairie MSARC4 pose un problème ?

Pour la rapidité, tout ceci est bien relatif car j'imagine que cela
dépend du flux à traiter.
En ce qui me concerne, mon problème est le chiffrement de sessions à
distance (type VNC) (sans l'utilisation de tunnel car la mise en place
doit être immédiate et très simple et en plus - plutôt en moins :) -
uniquement sur Windows). Le chiffrement doit être aussi "temps réel" que
possible.
Egalement le chiffrement de données pour un backup distant. Pour
quelques dizaines de Mo, on s'en fout, mais pour quelques dizaines de
Go, passer de RC4 à
Je me pose également la question quant à la diminution de débit et
l'augmentation de charge processeur pour du wifi domestique (donc
utilisant des chipset pas du tout optimisés pour du WPA ou WPA2).
Pour finir,

Je comprends que l'on demande à un solution de chiffrement d'être
surtout robuste, et je pensais que RC4 l'était largement "assez". Mais,
comme son nom d'indique, AES a été fait pour qu'on propose du
chiffrement avancé. Ai-je besoin d'autant que cela, je ne sais pas, mais
je souhaite avant tout la plus grande rapidité possible.

Si on me dit que le chiffrement peut être cassé en brute par une grappe
de 1000 UC en quelques heures, c'est pas trop grave. Si on me dit qu'il
peut être cassée à cause d'un attracteur étrange sur la clé elliptique
de l'espace ultra-dimensionnel en matrice active ( :D j'adore dire
n'importe quoi, ça me rappelle Gotlieb) en 5 heures, ça me gêne
davantage. Donc exit XOR et les algo de Lheureux ;)

Vous avez filtré cet utilisateur ! Consultez son message

Pour répondre à vos questions:
- oui, Rijndael (l'AES) est bien plus lent que RC4, mais il a été
pensé pour être optimisé sur différentes architectures, allant de
la carte à puce 8 bits aux processeurs 64 bits, et c'est le plus
rapide des finalistes au concours AES; de plus, il n'est pas si
lent dans l'absolu, mon poste de dev (P4 3GHz) chiffre en AES des
blocs de 256 octets à la vitesse de 110Mo/s, donc bien plus vite
que le débit de mes disques durs, ou de ma carte réseau,
- on demande tout d'abord à une solution de chiffrement d'être
robuste, avant d'être rapide (sinon, on fait un xor avec un octet
constant), et de ce point de vue, l'AES est bien plus robuste que
RC4.

Ok. Merci. J'ignorais qu'il y avait des problèmes de sécurité avec
(A)RC4. La librairie MSARC4 pose un problème ?

Pour la rapidité, tout ceci est bien relatif car j'imagine que cela
dépend du flux à traiter.
En ce qui me concerne, mon problème est le chiffrement de sessions à
distance (type VNC) (sans l'utilisation de tunnel car la mise en place
doit être immédiate et très simple et en plus - plutôt en moins :) -
uniquement sur Windows). Le chiffrement doit être aussi "temps réel" que
possible.
Egalement le chiffrement de données pour un backup distant. Pour
quelques dizaines de Mo, on s'en fout, mais pour quelques dizaines de
Go, passer de RC4 à
Je me pose également la question quant à la diminution de débit et
l'augmentation de charge processeur pour du wifi domestique (donc
utilisant des chipset pas du tout optimisés pour du WPA ou WPA2).
Pour finir,

Je comprends que l'on demande à un solution de chiffrement d'être
surtout robuste, et je pensais que RC4 l'était largement "assez". Mais,
comme son nom d'indique, AES a été fait pour qu'on propose du
chiffrement avancé. Ai-je besoin d'autant que cela, je ne sais pas, mais
je souhaite avant tout la plus grande rapidité possible.

Si on me dit que le chiffrement peut être cassé en brute par une grappe
de 1000 UC en quelques heures, c'est pas trop grave. Si on me dit qu'il
peut être cassée à cause d'un attracteur étrange sur la clé elliptique
de l'espace ultra-dimensionnel en matrice active ( :D j'adore dire
n'importe quoi, ça me rappelle Gotlieb) en 5 heures, ça me gêne
davantage. Donc exit XOR et les algo de Lheureux ;)

Eric Lalitte

20/10/2006 à 21:02

"Olivier Masson" wrote in message
news:4537592d$0$8610$

un peu partout, AES s'impose. C'est la grande mode de WPA2 avec son
AES-CCMP.
Pourtant AES est bien plus lent que RC4.

Mais il me semble que ce deux algorithmes n'ont pas du tout les mêmes
fonctionnalités.
RC4 est pour générer une suite d'octets pseudo aléatoire.
AES est un algorithme de chiffrement symétrique.

Donc si je ne me plante pas (ce qui est quand même un peu pseudo
aléatoire aussi) ces deux algorithmes ne peuvent pas être comparés.

Alors y'a t'il une raison
valable, si l'on ne souhaite pas chiffrer des infos classées Très Secret
Défense, d'utiliser AES plutôt que RC4 ?

Ben, AES est le successeur de DES/3DES dans la famille des algos
symétriques. Il est pas cassé, puissant et évolutif et approuvé
par la NSA... donc que demande de plus le peuple ? ;-)

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Fabien LE LEZ

20/10/2006 à 23:21

On 20 Oct 2006 19:02:45 GMT, "Eric Lalitte" :

Il est pas cassé, puissant et évolutif et approuvé
par la NSA... donc que demande de plus le peuple ? ;-)

Un algo que la NSA n'approuve pas parce qu'elle ne sait pas le
décrypter ?

Olivier Masson

21/10/2006 à 02:30

RC4 est pour générer une suite d'octets pseudo aléatoire.
AES est un algorithme de chiffrement symétrique.

RC4 est utilisé pour le chiffrement comme AES.

Ben, AES est le successeur de DES/3DES dans la famille des algos
symétriques. Il est pas cassé, puissant et évolutif et approuvé
par la NSA... donc que demande de plus le peuple ? ;-)

Quelque chose de plus rapide, comme RC4 (bon, ARC4 ok) qui doit être pas
loin de 10x plus rapide qu'AES.
De plus, bcp des participants à l'AES ne sont pas cassés, puissants (et
évolutif ? Je ne comprend pas ce que ça signifie).

Erwann ABALEA

21/10/2006 à 11:50

Hodie XIII Kal. Nov. MMVI est, Olivier Masson scripsit:

Pour répondre à vos questions:
- oui, Rijndael (l'AES) est bien plus lent que RC4, mais il a été
pensé pour être optimisé sur différentes architectures, allant de
la carte à puce 8 bits aux processeurs 64 bits, et c'est le plus
rapide des finalistes au concours AES; de plus, il n'est pas si
lent dans l'absolu, mon poste de dev (P4 3GHz) chiffre en AES des
blocs de 256 octets à la vitesse de 110Mo/s, donc bien plus vite
que le débit de mes disques durs, ou de ma carte réseau,
- on demande tout d'abord à une solution de chiffrement d'être
robuste, avant d'être rapide (sinon, on fait un xor avec un octet
constant), et de ce point de vue, l'AES est bien plus robuste que
RC4.

Ok. Merci. J'ignorais qu'il y avait des problèmes de sécurité avec (A)RC4. La librairie MSARC4 pose un problème ?

Je ne connais pas cette bibliothèque, mais à mon avis, elle ne fournit
que l'accès aux primitives ARC4, et ça, c'est tellement simple, qu'on
imagine mal une erreur d'implémentation.
Il y a au moins 2 problèmes:
- il *faut* jeter les premiers octets du générateur ARC4 (les 256
premiers, par exemple), qui sont fortement biaisés
- avec une taille suffisante de données, on peut distinguer un flux
ARC4 d'un flux aléatoire

Ca, c'est juste pour ARC4. Se posent aussi les problèmes liés à un
stream cipher, comme l'est ARC4. Voir par exemple
http://eprint.iacr.org/2005/007/

En ce qui me concerne, mon problème est le chiffrement de sessions à distance (type VNC) (sans l'utilisation de tunnel car la mise en place doit être
immédiate et très simple et en plus - plutôt en moins :) - uniquement sur Windows). Le chiffrement doit être aussi "temps réel" que possible.
Egalement le chiffrement de données pour un backup distant. Pour quelques dizaines de Mo, on s'en fout, mais pour quelques dizaines de Go, passer de RC4 à

L'argument de la performance est très tentant, je comprend, c'est une
question de confort... Pour le VNC, trouver une bonne implémentation
d'AES, et le chiffrement ne sera pas un goulet d'étranglement.

Je me pose également la question quant à la diminution de débit et l'augmentation de charge processeur pour du wifi domestique (donc utilisant des chipset
pas du tout optimisés pour du WPA ou WPA2).

Les prochains le seront.
On trouve déjà des CPU avec du silicium fait pour l'AES (les VIA
PadLock). Pour la justification de l'AES dans WPA, voir par exemple:
http://grouper.ieee.org/groups/802/20/Contribs/C802.20-04-65.ppt

Dans ce document, le projet Nessie est également cité (une sorte de
concours, comme celui qui avait pour but l'AES, mais cette fois ci
pour plusieurs types de primitives crypto), et en effet, des quelques
candidats dans la catégorie stream cipher, aucun n'a été retenu.

Je comprends que l'on demande à un solution de chiffrement d'être surtout robuste, et je pensais que RC4 l'était largement "assez". Mais, comme son nom
d'indique, AES a été fait pour qu'on propose du chiffrement avancé. Ai-je besoin d'autant que cela, je ne sais pas, mais je souhaite avant tout la plus
grande rapidité possible.

Là, c'est à vous de décider par et pour vous même du poids à accorder
à la performance et à la sécurité. Si votre produit sort de votre
usage exclusif, gardez à l'esprit que d'autres auront d'autres
besoins. Prevoyez donc de l'AES, en plus de ARC4.

On peut quand même utiliser ARC4, s'il est correctement employé. Par
exemple, tel que la couche SSL/TLS l'utilise, ça marche, c'est
robuste. Mais il suffit de dévier un tout petit peu, et blam, la
sanction. Le lien eprint ci-dessus, et le WEP/WEP2 sont 2 exemples.

Donc exit XOR et les algo de Lheureux ;)

C'est Bien (tm). :)

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
``Do you want protocols that look nice or protocols that work nice?''
Mike Padlipsky, internet architect

Hodie XIII Kal. Nov. MMVI est, Olivier Masson scripsit:

Pour répondre à vos questions:
- oui, Rijndael (l'AES) est bien plus lent que RC4, mais il a été
pensé pour être optimisé sur différentes architectures, allant de
la carte à puce 8 bits aux processeurs 64 bits, et c'est le plus
rapide des finalistes au concours AES; de plus, il n'est pas si
lent dans l'absolu, mon poste de dev (P4 3GHz) chiffre en AES des
blocs de 256 octets à la vitesse de 110Mo/s, donc bien plus vite
que le débit de mes disques durs, ou de ma carte réseau,
- on demande tout d'abord à une solution de chiffrement d'être
robuste, avant d'être rapide (sinon, on fait un xor avec un octet
constant), et de ce point de vue, l'AES est bien plus robuste que
RC4.

Ok. Merci. J'ignorais qu'il y avait des problèmes de sécurité avec (A)RC4. La librairie MSARC4 pose un problème ?

Je ne connais pas cette bibliothèque, mais à mon avis, elle ne fournit
que l'accès aux primitives ARC4, et ça, c'est tellement simple, qu'on
imagine mal une erreur d'implémentation.
Il y a au moins 2 problèmes:
- il *faut* jeter les premiers octets du générateur ARC4 (les 256
premiers, par exemple), qui sont fortement biaisés
- avec une taille suffisante de données, on peut distinguer un flux
ARC4 d'un flux aléatoire

Ca, c'est juste pour ARC4. Se posent aussi les problèmes liés à un
stream cipher, comme l'est ARC4. Voir par exemple
http://eprint.iacr.org/2005/007/

En ce qui me concerne, mon problème est le chiffrement de sessions à distance (type VNC) (sans l'utilisation de tunnel car la mise en place doit être
immédiate et très simple et en plus - plutôt en moins :) - uniquement sur Windows). Le chiffrement doit être aussi "temps réel" que possible.
Egalement le chiffrement de données pour un backup distant. Pour quelques dizaines de Mo, on s'en fout, mais pour quelques dizaines de Go, passer de RC4 à

L'argument de la performance est très tentant, je comprend, c'est une
question de confort... Pour le VNC, trouver une bonne implémentation
d'AES, et le chiffrement ne sera pas un goulet d'étranglement.

Je me pose également la question quant à la diminution de débit et l'augmentation de charge processeur pour du wifi domestique (donc utilisant des chipset
pas du tout optimisés pour du WPA ou WPA2).

Les prochains le seront.
On trouve déjà des CPU avec du silicium fait pour l'AES (les VIA
PadLock). Pour la justification de l'AES dans WPA, voir par exemple:
http://grouper.ieee.org/groups/802/20/Contribs/C802.20-04-65.ppt

Dans ce document, le projet Nessie est également cité (une sorte de
concours, comme celui qui avait pour but l'AES, mais cette fois ci
pour plusieurs types de primitives crypto), et en effet, des quelques
candidats dans la catégorie stream cipher, aucun n'a été retenu.

Je comprends que l'on demande à un solution de chiffrement d'être surtout robuste, et je pensais que RC4 l'était largement "assez". Mais, comme son nom
d'indique, AES a été fait pour qu'on propose du chiffrement avancé. Ai-je besoin d'autant que cela, je ne sais pas, mais je souhaite avant tout la plus
grande rapidité possible.

Là, c'est à vous de décider par et pour vous même du poids à accorder
à la performance et à la sécurité. Si votre produit sort de votre
usage exclusif, gardez à l'esprit que d'autres auront d'autres
besoins. Prevoyez donc de l'AES, en plus de ARC4.

On peut quand même utiliser ARC4, s'il est correctement employé. Par
exemple, tel que la couche SSL/TLS l'utilise, ça marche, c'est
robuste. Mais il suffit de dévier un tout petit peu, et blam, la
sanction. Le lien eprint ci-dessus, et le WEP/WEP2 sont 2 exemples.

Donc exit XOR et les algo de Lheureux ;)

C'est Bien (tm). :)

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
``Do you want protocols that look nice or protocols that work nice?''
Mike Padlipsky, internet architect

Vous avez filtré cet utilisateur ! Consultez son message

Hodie XIII Kal. Nov. MMVI est, Olivier Masson scripsit:

Pour répondre à vos questions:
- oui, Rijndael (l'AES) est bien plus lent que RC4, mais il a été
pensé pour être optimisé sur différentes architectures, allant de
la carte à puce 8 bits aux processeurs 64 bits, et c'est le plus
rapide des finalistes au concours AES; de plus, il n'est pas si
lent dans l'absolu, mon poste de dev (P4 3GHz) chiffre en AES des
blocs de 256 octets à la vitesse de 110Mo/s, donc bien plus vite
que le débit de mes disques durs, ou de ma carte réseau,
- on demande tout d'abord à une solution de chiffrement d'être
robuste, avant d'être rapide (sinon, on fait un xor avec un octet
constant), et de ce point de vue, l'AES est bien plus robuste que
RC4.

Ok. Merci. J'ignorais qu'il y avait des problèmes de sécurité avec (A)RC4. La librairie MSARC4 pose un problème ?

Je ne connais pas cette bibliothèque, mais à mon avis, elle ne fournit
que l'accès aux primitives ARC4, et ça, c'est tellement simple, qu'on
imagine mal une erreur d'implémentation.
Il y a au moins 2 problèmes:
- il *faut* jeter les premiers octets du générateur ARC4 (les 256
premiers, par exemple), qui sont fortement biaisés
- avec une taille suffisante de données, on peut distinguer un flux
ARC4 d'un flux aléatoire

Ca, c'est juste pour ARC4. Se posent aussi les problèmes liés à un
stream cipher, comme l'est ARC4. Voir par exemple
http://eprint.iacr.org/2005/007/

En ce qui me concerne, mon problème est le chiffrement de sessions à distance (type VNC) (sans l'utilisation de tunnel car la mise en place doit être
immédiate et très simple et en plus - plutôt en moins :) - uniquement sur Windows). Le chiffrement doit être aussi "temps réel" que possible.
Egalement le chiffrement de données pour un backup distant. Pour quelques dizaines de Mo, on s'en fout, mais pour quelques dizaines de Go, passer de RC4 à

L'argument de la performance est très tentant, je comprend, c'est une
question de confort... Pour le VNC, trouver une bonne implémentation
d'AES, et le chiffrement ne sera pas un goulet d'étranglement.

Je me pose également la question quant à la diminution de débit et l'augmentation de charge processeur pour du wifi domestique (donc utilisant des chipset
pas du tout optimisés pour du WPA ou WPA2).

Les prochains le seront.
On trouve déjà des CPU avec du silicium fait pour l'AES (les VIA
PadLock). Pour la justification de l'AES dans WPA, voir par exemple:
http://grouper.ieee.org/groups/802/20/Contribs/C802.20-04-65.ppt

Dans ce document, le projet Nessie est également cité (une sorte de
concours, comme celui qui avait pour but l'AES, mais cette fois ci
pour plusieurs types de primitives crypto), et en effet, des quelques
candidats dans la catégorie stream cipher, aucun n'a été retenu.

Je comprends que l'on demande à un solution de chiffrement d'être surtout robuste, et je pensais que RC4 l'était largement "assez". Mais, comme son nom
d'indique, AES a été fait pour qu'on propose du chiffrement avancé. Ai-je besoin d'autant que cela, je ne sais pas, mais je souhaite avant tout la plus
grande rapidité possible.

Là, c'est à vous de décider par et pour vous même du poids à accorder
à la performance et à la sécurité. Si votre produit sort de votre
usage exclusif, gardez à l'esprit que d'autres auront d'autres
besoins. Prevoyez donc de l'AES, en plus de ARC4.

On peut quand même utiliser ARC4, s'il est correctement employé. Par
exemple, tel que la couche SSL/TLS l'utilise, ça marche, c'est
robuste. Mais il suffit de dévier un tout petit peu, et blam, la
sanction. Le lien eprint ci-dessus, et le WEP/WEP2 sont 2 exemples.

Donc exit XOR et les algo de Lheureux ;)

C'est Bien (tm). :)

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
``Do you want protocols that look nice or protocols that work nice?''
Mike Padlipsky, internet architect

Eric Lalitte

22/10/2006 à 17:26

"Olivier Masson" wrote in message
news:453948cd$0$16104$

RC4 est utilisé pour le chiffrement comme AES.

Tu semblais parler de RC4 dans le cadre du wep ou wpa dans lequel il ne
sert pas à chiffrer mais juste à produire une source pseudo-aleatoire,
qui servira à son tour de clef de chiffrement pour le one time pad.
AES sert d'algorithme de chiffrement symétrique par blocs, ce qui, je
pense, n'est pas comparable avec un algorithme de chiffrement
symétrique par flux.

Quelque chose de plus rapide, comme RC4 (bon, ARC4 ok) qui doit être pas
loin de 10x plus rapide qu'AES.

Si ton objectif est la rapidité, je comprends, mais il y a certains
autres critères à prendre en compte pour obtenir aussi le niveau de
sécurité requis (oui, l'implémentation de RC4 dans le wep était une
erreur, mais il y a un cadre d'utilisation qui n'a pas été respecté, et
qui doit entrer en ligne de compte lorsqu'on fait le choix d'un
algorithme)

De plus, bcp des participants à l'AES ne sont pas cassés, puissants (et
évolutif ? Je ne comprend pas ce que ça signifie).

Cela signifie que l'algorithme a été pensé pour avoir une durée de vie
supérieure à 2 semaines :-)

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Olivier Masson

22/10/2006 à 18:37

Je ne connais pas cette bibliothèque, mais à mon avis, elle ne fournit
que l'accès aux primitives ARC4, et ça, c'est tellement simple, qu'on
imagine mal une erreur d'implémentation.
Il y a au moins 2 problèmes:
- il *faut* jeter les premiers octets du générateur ARC4 (les 256
premiers, par exemple), qui sont fortement biaisés
- avec une taille suffisante de données, on peut distinguer un flux
ARC4 d'un flux aléatoire

Ca, c'est juste pour ARC4. Se posent aussi les problèmes liés à un
stream cipher, comme l'est ARC4. Voir par exemple
http://eprint.iacr.org/2005/007/

Merci bcp pour ces précisions.

L'argument de la performance est très tentant, je comprend, c'est une
question de confort... Pour le VNC, trouver une bonne implémentation
d'AES, et le chiffrement ne sera pas un goulet d'étranglement.

Mes connaissances ne me permettent *pas du tout* de savoir si
l'implémentation d'AES est "bonne". J'utilise ça :
http://msrc4plugin.home.comcast.net/aesv2plugin.html conjointement avec
UltraVNC (uniquement sous windows fort malheureusement mais qui a des
fonctionnalités très utiles - video driver hook, single click, repeater,
chat, etc. -).

Les prochains le seront.
On trouve déjà des CPU avec du silicium fait pour l'AES (les VIA
PadLock). Pour la justification de l'AES dans WPA, voir par exemple:
http://grouper.ieee.org/groups/802/20/Contribs/C802.20-04-65.ppt

Ah oui, il me semble que ces VIA sont présents dans les dedibox, ce qui
pourrait donc s'avérer intéressant pour du backup.
Le document que tu donnes, comme ce qu'on lit partout, justifie
l'utilisation d'AES par le fait qu'il soit plus puissant. Certes. Et que
WEP était tellement pourri qu'il fallait qq chose de parfait pour sa
relève. Bon. Mais quand on voit que AES ne permet que 63Mo/s sur un
Opteron 1.6GHz, ça reste très faiblard. Par contre, je pensais que RC4
était plus rapide donc, au final, c'est le peu de différence (qd même un
facteur 2) qui me convainc de passer à Rijndael.

On peut quand même utiliser ARC4, s'il est correctement employé. Par
exemple, tel que la couche SSL/TLS l'utilise, ça marche, c'est
robuste. Mais il suffit de dévier un tout petit peu, et blam, la
sanction. Le lien eprint ci-dessus, et le WEP/WEP2 sont 2 exemples.

J'ai compris la leçon :)

Merci pour cette réponse.

Je ne connais pas cette bibliothèque, mais à mon avis, elle ne fournit
que l'accès aux primitives ARC4, et ça, c'est tellement simple, qu'on
imagine mal une erreur d'implémentation.
Il y a au moins 2 problèmes:
- il *faut* jeter les premiers octets du générateur ARC4 (les 256
premiers, par exemple), qui sont fortement biaisés
- avec une taille suffisante de données, on peut distinguer un flux
ARC4 d'un flux aléatoire

Ca, c'est juste pour ARC4. Se posent aussi les problèmes liés à un
stream cipher, comme l'est ARC4. Voir par exemple
http://eprint.iacr.org/2005/007/

Merci bcp pour ces précisions.

L'argument de la performance est très tentant, je comprend, c'est une
question de confort... Pour le VNC, trouver une bonne implémentation
d'AES, et le chiffrement ne sera pas un goulet d'étranglement.

Mes connaissances ne me permettent *pas du tout* de savoir si
l'implémentation d'AES est "bonne". J'utilise ça :
http://msrc4plugin.home.comcast.net/aesv2plugin.html conjointement avec
UltraVNC (uniquement sous windows fort malheureusement mais qui a des
fonctionnalités très utiles - video driver hook, single click, repeater,
chat, etc. -).

Les prochains le seront.
On trouve déjà des CPU avec du silicium fait pour l'AES (les VIA
PadLock). Pour la justification de l'AES dans WPA, voir par exemple:
http://grouper.ieee.org/groups/802/20/Contribs/C802.20-04-65.ppt

Ah oui, il me semble que ces VIA sont présents dans les dedibox, ce qui
pourrait donc s'avérer intéressant pour du backup.
Le document que tu donnes, comme ce qu'on lit partout, justifie
l'utilisation d'AES par le fait qu'il soit plus puissant. Certes. Et que
WEP était tellement pourri qu'il fallait qq chose de parfait pour sa
relève. Bon. Mais quand on voit que AES ne permet que 63Mo/s sur un
Opteron 1.6GHz, ça reste très faiblard. Par contre, je pensais que RC4
était plus rapide donc, au final, c'est le peu de différence (qd même un
facteur 2) qui me convainc de passer à Rijndael.

On peut quand même utiliser ARC4, s'il est correctement employé. Par
exemple, tel que la couche SSL/TLS l'utilise, ça marche, c'est
robuste. Mais il suffit de dévier un tout petit peu, et blam, la
sanction. Le lien eprint ci-dessus, et le WEP/WEP2 sont 2 exemples.

J'ai compris la leçon :)

Merci pour cette réponse.

Vous avez filtré cet utilisateur ! Consultez son message

Je ne connais pas cette bibliothèque, mais à mon avis, elle ne fournit
que l'accès aux primitives ARC4, et ça, c'est tellement simple, qu'on
imagine mal une erreur d'implémentation.
Il y a au moins 2 problèmes:
- il *faut* jeter les premiers octets du générateur ARC4 (les 256
premiers, par exemple), qui sont fortement biaisés
- avec une taille suffisante de données, on peut distinguer un flux
ARC4 d'un flux aléatoire

Ca, c'est juste pour ARC4. Se posent aussi les problèmes liés à un
stream cipher, comme l'est ARC4. Voir par exemple
http://eprint.iacr.org/2005/007/

Merci bcp pour ces précisions.

L'argument de la performance est très tentant, je comprend, c'est une
question de confort... Pour le VNC, trouver une bonne implémentation
d'AES, et le chiffrement ne sera pas un goulet d'étranglement.

Mes connaissances ne me permettent *pas du tout* de savoir si
l'implémentation d'AES est "bonne". J'utilise ça :
http://msrc4plugin.home.comcast.net/aesv2plugin.html conjointement avec
UltraVNC (uniquement sous windows fort malheureusement mais qui a des
fonctionnalités très utiles - video driver hook, single click, repeater,
chat, etc. -).

Les prochains le seront.
On trouve déjà des CPU avec du silicium fait pour l'AES (les VIA
PadLock). Pour la justification de l'AES dans WPA, voir par exemple:
http://grouper.ieee.org/groups/802/20/Contribs/C802.20-04-65.ppt

Ah oui, il me semble que ces VIA sont présents dans les dedibox, ce qui
pourrait donc s'avérer intéressant pour du backup.
Le document que tu donnes, comme ce qu'on lit partout, justifie
l'utilisation d'AES par le fait qu'il soit plus puissant. Certes. Et que
WEP était tellement pourri qu'il fallait qq chose de parfait pour sa
relève. Bon. Mais quand on voit que AES ne permet que 63Mo/s sur un
Opteron 1.6GHz, ça reste très faiblard. Par contre, je pensais que RC4
était plus rapide donc, au final, c'est le peu de différence (qd même un
facteur 2) qui me convainc de passer à Rijndael.

On peut quand même utiliser ARC4, s'il est correctement employé. Par
exemple, tel que la couche SSL/TLS l'utilise, ça marche, c'est
robuste. Mais il suffit de dévier un tout petit peu, et blam, la
sanction. Le lien eprint ci-dessus, et le WEP/WEP2 sont 2 exemples.

J'ai compris la leçon :)

Merci pour cette réponse.

Pourquoi de l'AES partout (notamment WPA2) ?

8 réponses

Veuillez sélectionner un problème