RC4 par blocks

Le
FB
Bonjour,

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 à ch=
aque
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.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
fbparis
Le #20250821
J'ai oublié de préciser que j'utilise de plus un algo RC4 modifié
écarte les 1024 premiers octets générés...

On 29 sep, 09:22, FB
Bonjour,

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 partie s
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.


Thomas Pornin
Le #20251751
According to FB
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
Le #20253251
Merci pour votre réponse, et pour le lien !

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 repos era
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
According to FB  
> J'ai besoin d'un algorithme de chiffrement de flux symétrique, RC4 es t
> 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 tou t
d'abord que cette question de rapidité est rarement importante ; il fau t
des conditions d'usage assez spéciales pour que la vitesse d'exécutio n
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 son t
générées. Refaire une clé pour chaque octet produit revient à u tiliser
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. L e 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ésu ltats ne
demandent qu'à être utilisés, cf eSTREAM (URL citée plus haut). L es
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 penc he 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_ cryptographi que
(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


Publicité
Poster une réponse
Anonyme