RC4 par blocks
FB
J'ai besoin d'un algorythme de chiffrement de flux symétrique, RC4 est
simple et rapide et je me demandais si en le modifiant de la façon
suivante ses vulnérabilités pouvaient disparaitre (pseudo code) :
block_RC4 ( key , msg, blockSize) =
foreach ( split ( msg, blockSize) as part)
(key , part) = RC4 ( key, key + part)
ret = ret + part
return ret
En gros, le flux a coder / decoder est décomposé en blocs et pour
chaque bloc on regénère une clef. Je pensais prendre une clef de
longueur maximale et des blocs de 512 caracteres.
Bien sur, si il y a à l'origine un secret partagé entre le client et
le serveur la clef initiale sera généree avec un vecteur
d'initialisation pour que le même message entre les deux mêmes parties
ne donne pas un résultat identique.
J'aurais tendance à penser que ce système est sûr, et si oui ma
deuxième interrogation est de savoir si avec la régénération à chaque
bloc, le processus devient moins rapide que par exemple AES mais cela
est moins important car je peux facilement faire des tests moi même
pour le savoir...
Merci d'avance pour vos lumières.
fbparis
écarte les 1024 premiers octets générés...
Thomas Pornin
> J'ai besoin d'un algorithme de chiffrement de flux sym�trique, RC4 est
> simple et rapide
En fait non. Enfin, pour la simplicit�, oui, RC4 est simple (tant qu'on
parle de logiciel), mais pour la rapidit�, on fait mieux. Rappelons tout
d'abord que cette question de rapidit� est rarement importante ; il faut
des conditions d'usage assez sp�ciales pour que la vitesse d'ex�cution
de l'algorithme lui-m�me soit un point limitant. Un PC compl�tement
basique peut parfaitement chiffrer des donn�es � la vitesse d'un lien
100 Mbits en utilisant 3DES, pourtant fort lent.
Ensuite, m�me dans le cadre restrictif du chiffrement de flux, on sait
faire plus rapide et plus s�r que RC4. cf :
http://www.ecrypt.eu.org/stream/
> et je me demandais si en le modifiant de la fa�on suivante ses
> vuln�rabilit�s pouvaient disparaitre
Non. Une des vuln�rabilit�s de RC4 est un biais statistique sur les
paires d'octets successifs. Pour �liminer ce biais, il faudrait
reg�n�rer une cl� pour _chaque octet_ produit. Attention : quand je dis
"il faudrait" je ne dis pas que �a suffirait pour rendre RC4 s�r ; �a
d�pendrait aussi beaucoup de la fa�on dont les cl�s successives sont
g�n�r�es. Refaire une cl� pour chaque octet produit revient � utiliser
l'initialisation de la cl� dans RC4 comme une fonction de hachage,
auquel cas, par sa structure, RC4 ressemble fortement � la fonction de
hachage MD2, qui est fort lente et fort peu s�re.
En bref, mauvaise id�e. Faire une variation maison en se disant que �a
donnera quelque chose de s�r est d�j� en soi une id�e boiteuse. Le seul
moyen connu pour produire des algorithmes qui ont une bonne chance
d'�tre s�rs est de faire plancher dessus quelques centaines de
sp�cialistes pendant plusieurs ann�es. C'est ce qui se passe dans la
recherche publique, qui sert pr�cis�ment � �a, et dont les r�sultats ne
demandent qu'� �tre utilis�s, cf eSTREAM (URL cit�e plus haut). Les
variantes manuelles appliqu�es dans un coin par un d�veloppeur bien
intentionn� mais solitaire, �a m�ne invariablement � des choses
cassables, et qui sont effectivement cass�es le jour o� un attaquant
suffisamment motiv� ou un �tudiant suffisamment d�soeuvr� se penche sur
le sujet. Donc ne le faites pas. Et, dans ce cas particulier, partir de
RC4 rajoute une couche de fragilit�, ce qui rend l'id�e encore moins
bonne.
Ceci �tant, rassurez-vous : il est hautement probable que votre syst�me
aura des vuln�rabilit� autrement plus criantes que les biais d'un RC4,
m�me modifi�. En effet, la construction d'un _protocole_ cryptographique
(i.e. l'assemblage d'un ou plusieurs algorithmes cryptographiques en un
syst�me de transport de donn�es) est _�galement_ quelque chose de
beaucoup plus difficile que ce qu'il en para�t. Par exemple, le
protocole SSL a �t� enfant� dans la douleur, selon un processus qui a
mis une bonne dizaine d'ann�es, �maill�s par diverses attaques plus ou
moins finaudes �manant de chercheurs divers. Des centaines de personnes
sp�cialis�es dans le sujet se sont pench�es sur SSL pendant ces dix ans.
Penser faire mieux, tout seul, en quelques mois, que des centaines de
sp�cialistes pendant dix ans, c'est, pour le moins, un peu ambitieux.
--Thomas Pornin
fbparis
J'ai bien conscience sinon que non seulement la plupart des données
que je vais crypter n'ont pas besoin d'un tel niveau de
confidentialité, mais aussi que la sécurité de mon système ne reposera
pas simplement sur cette petite partie, j'ai juste cette obsession de
toujours vouloir faire au mieux :)
J'en profite également pour vous féliciter pour toutes vos
interventions dans ce groupe que je suis vaguement depuis de
nombreuses années, votre prose est très didactique pour les profanes
dans mon genre !
François
On 29 sep, 13:13, Thomas Pornin <por...@bolet.org> wrote:
> According to FB <fbou...@gmail.com>:
>
> > J'ai besoin d'un algorithme de chiffrement de flux symétrique, RC4 est
> > simple et rapide
>
> En fait non. Enfin, pour la simplicité, oui, RC4 est simple (tant qu'on
> parle de logiciel), mais pour la rapidité, on fait mieux. Rappelons tout
> d'abord que cette question de rapidité est rarement importante ; il faut
> des conditions d'usage assez spéciales pour que la vitesse d'exécution
> de l'algorithme lui-même soit un point limitant. Un PC complètement
> basique peut parfaitement chiffrer des données à la vitesse d'un lien
> 100 Mbits en utilisant 3DES, pourtant fort lent.
>
> Ensuite, même dans le cadre restrictif du chiffrement de flux, on sait
> faire plus rapide et plus sûr que RC4. cf :
> http://www.ecrypt.eu.org/stream/
>
> > et je me demandais si en le modifiant de la façon suivante ses
> > vulnérabilités pouvaient disparaitre
>
> Non. Une des vulnérabilités de RC4 est un biais statistique sur les
> paires d'octets successifs. Pour éliminer ce biais, il faudrait
> regénérer une clé pour _chaque octet_ produit. Attention : quand je dis
> "il faudrait" je ne dis pas que ça suffirait pour rendre RC4 sûr ; ça
> dépendrait aussi beaucoup de la façon dont les clés successives sont
> générées. Refaire une clé pour chaque octet produit revient à utiliser
> l'initialisation de la clé dans RC4 comme une fonction de hachage,
> auquel cas, par sa structure, RC4 ressemble fortement à la fonction de
> hachage MD2, qui est fort lente et fort peu sûre.
>
> En bref, mauvaise idée. Faire une variation maison en se disant que ça
> donnera quelque chose de sûr est déjà en soi une idée boiteuse. Le seul
> moyen connu pour produire des algorithmes qui ont une bonne chance
> d'être sûrs est de faire plancher dessus quelques centaines de
> spécialistes pendant plusieurs années. C'est ce qui se passe dans la
> recherche publique, qui sert précisément à ça, et dont les résultats ne
> demandent qu'à être utilisés, cf eSTREAM (URL citée plus haut). Les
> variantes manuelles appliquées dans un coin par un développeur bien
> intentionné mais solitaire, ça mène invariablement à des choses
> cassables, et qui sont effectivement cassées le jour où un attaquant
> suffisamment motivé ou un étudiant suffisamment désoeuvré se penche sur
> le sujet. Donc ne le faites pas. Et, dans ce cas particulier, partir de
> RC4 rajoute une couche de fragilité, ce qui rend l'idée encore moins
> bonne.
>
> Ceci étant, rassurez-vous : il est hautement probable que votre système
> aura des vulnérabilité autrement plus criantes que les biais d'un RC4,
> même modifié. En effet, la construction d'un _protocole_ cryptographique
> (i.e. l'assemblage d'un ou plusieurs algorithmes cryptographiques en un
> système de transport de données) est _également_ quelque chose de
> beaucoup plus difficile que ce qu'il en paraît. Par exemple, le
> protocole SSL a été enfanté dans la douleur, selon un processus qui a
> mis une bonne dizaine d'années, émaillés par diverses attaques plus ou
> moins finaudes émanant de chercheurs divers. Des centaines de personnes
> spécialisées dans le sujet se sont penchées sur SSL pendant ces dix ans.
> Penser faire mieux, tout seul, en quelques mois, que des centaines de
> spécialistes pendant dix ans, c'est, pour le moins, un peu ambitieux.
>
> --Thomas Pornin