J'ai besoin d'un algorythme de chiffrement de flux sym=E9trique, RC4 est
simple et rapide et je me demandais si en le modifiant de la fa=E7on
suivante ses vuln=E9rabilit=E9s pouvaient disparaitre (pseudo code) :
block_RC4 ( key , msg, blockSize) =3D
foreach ( split ( msg, blockSize) as part)
(key , part) =3D RC4 ( key, key + part)
ret =3D ret + part
return ret
En gros, le flux a coder / decoder est d=E9compos=E9 en blocs et pour
chaque bloc on reg=E9n=E8re une clef. Je pensais prendre une clef de
longueur maximale et des blocs de 512 caracteres.
Bien sur, si il y a =E0 l'origine un secret partag=E9 entre le client et
le serveur la clef initiale sera g=E9n=E9ree avec un vecteur
d'initialisation pour que le m=EAme message entre les deux m=EAmes parties
ne donne pas un r=E9sultat identique.
J'aurais tendance =E0 penser que ce syst=E8me est s=FBr, et si oui ma
deuxi=E8me interrogation est de savoir si avec la r=E9g=E9n=E9ration =E0 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=EAme
pour le savoir...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
fbparis
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 wrote:
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.
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 <fbou...@gmail.com> wrote:
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...
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 wrote:
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
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
According to FB <fboudot@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.
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
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 wrote:
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
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 <por...@bolet.org> wrote:
According to FB <fbou...@gmail.com>:
> 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.
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 wrote:
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.
