j'ai un P166 avec 32M Ram (avec un DD de 1Go mais bon ca peut se
changer)
et je cherche desesperement la maniere de le recycler ( oui par
nostalgie)
j'ai un P166 avec 32M Ram (avec un DD de 1Go mais bon ca peut se
changer)
et je cherche desesperement la maniere de le recycler ( oui par
nostalgie)
j'ai un P166 avec 32M Ram (avec un DD de 1Go mais bon ca peut se
changer)
et je cherche desesperement la maniere de le recycler ( oui par
nostalgie)
On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:On Fri, 9 Jan 2004, no_spam wrote:On Fri, 09 Jan 2004 13:42:18 +0100, El NiKo wrote:
Je ne l'utilise pas comme routeur/firewall pour deux raisons:
- il plafonne à 1 Mbit/s en cryptage SSH (avec blowfish), ce qui
est un peu léger.
Oublie Blowfish, prend AES (s'il est dispo sur ton serveur et ton
client). C'est plus rapide, c'est le standard, ça a été bien analysé.
Ou alors tu préfères le risque, et tu prends arcfour (RC4). C'est
*nettement* plus rapide, et ça tient la route si c'est bien utilisé (c'est
généralement là le problème).
J'ai essayé tous les cypher que ssh me présentait, et blowfish était
le plus rapide.
Il est possible que je n'ai pas bien configuré la Gentoo
et qu'il n'ai pas inclus l'AES. Il faut que je regarde.
On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:
On Fri, 9 Jan 2004, no_spam wrote:
On Fri, 09 Jan 2004 13:42:18 +0100, El NiKo wrote:
Je ne l'utilise pas comme routeur/firewall pour deux raisons:
- il plafonne à 1 Mbit/s en cryptage SSH (avec blowfish), ce qui
est un peu léger.
Oublie Blowfish, prend AES (s'il est dispo sur ton serveur et ton
client). C'est plus rapide, c'est le standard, ça a été bien analysé.
Ou alors tu préfères le risque, et tu prends arcfour (RC4). C'est
*nettement* plus rapide, et ça tient la route si c'est bien utilisé (c'est
généralement là le problème).
J'ai essayé tous les cypher que ssh me présentait, et blowfish était
le plus rapide.
Il est possible que je n'ai pas bien configuré la Gentoo
et qu'il n'ai pas inclus l'AES. Il faut que je regarde.
On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:On Fri, 9 Jan 2004, no_spam wrote:On Fri, 09 Jan 2004 13:42:18 +0100, El NiKo wrote:
Je ne l'utilise pas comme routeur/firewall pour deux raisons:
- il plafonne à 1 Mbit/s en cryptage SSH (avec blowfish), ce qui
est un peu léger.
Oublie Blowfish, prend AES (s'il est dispo sur ton serveur et ton
client). C'est plus rapide, c'est le standard, ça a été bien analysé.
Ou alors tu préfères le risque, et tu prends arcfour (RC4). C'est
*nettement* plus rapide, et ça tient la route si c'est bien utilisé (c'est
généralement là le problème).
J'ai essayé tous les cypher que ssh me présentait, et blowfish était
le plus rapide.
Il est possible que je n'ai pas bien configuré la Gentoo
et qu'il n'ai pas inclus l'AES. Il faut que je regarde.
Bipède wrote:Rhâââââ ! Y' a pas à dire mais Linux c'est le pieds !
Non, c'est un OS
Bipède wrote:
Rhâââââ ! Y' a pas à dire mais Linux c'est le pieds !
Non, c'est un OS
Bipède wrote:Rhâââââ ! Y' a pas à dire mais Linux c'est le pieds !
Non, c'est un OS
Bonjour,
On Sat, 10 Jan 2004, no_spam wrote:On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:On Fri, 9 Jan 2004, no_spam wrote:On Fri, 09 Jan 2004 13:42:18 +0100, El NiKo wrote:
Je ne l'utilise pas comme routeur/firewall pour deux raisons:
- il plafonne à 1 Mbit/s en cryptage SSH (avec blowfish), ce qui
est un peu léger.
Oublie Blowfish, prend AES (s'il est dispo sur ton serveur et ton
client). C'est plus rapide, c'est le standard, ça a été bien analysé.
Ou alors tu préfères le risque, et tu prends arcfour (RC4). C'est
*nettement* plus rapide, et ça tient la route si c'est bien utilisé (c'est
généralement là le problème).
J'ai essayé tous les cypher que ssh me présentait, et blowfish était
le plus rapide.
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
-----
:~$ openssl speed blowfish des rc2 idea rc4 rc5
...
BlowFish s'en sort plutôt bien; je n'ai pas d'AES sur cette version
d'OpenSSL (et peut-être que toi non plus), mais par design AES est plus
rapide que Blowfish (pour un même effort d'optimisation, bien entendu);
RC4 est de très loin le plus rapide (et c'est normal, quand on sait
comment ça marche). Blowfish a également un problème à l'initialisation de
la clé, c'est de très loin le plus lent de tous dans ce cas (ça n'est pas
indiqué ici), ça *peut* avoir un impact lors d'un grand nombre de
connexions.
Les flags utilisés pour compiler OpenSSL peuvent donner de sérieuses
différences en terme de perfs (plus que pour d'autres applis
'classiques').
Bonjour,
On Sat, 10 Jan 2004, no_spam wrote:
On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:
On Fri, 9 Jan 2004, no_spam wrote:
On Fri, 09 Jan 2004 13:42:18 +0100, El NiKo wrote:
Je ne l'utilise pas comme routeur/firewall pour deux raisons:
- il plafonne à 1 Mbit/s en cryptage SSH (avec blowfish), ce qui
est un peu léger.
Oublie Blowfish, prend AES (s'il est dispo sur ton serveur et ton
client). C'est plus rapide, c'est le standard, ça a été bien analysé.
Ou alors tu préfères le risque, et tu prends arcfour (RC4). C'est
*nettement* plus rapide, et ça tient la route si c'est bien utilisé (c'est
généralement là le problème).
J'ai essayé tous les cypher que ssh me présentait, et blowfish était
le plus rapide.
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
-----
eabalea@shining:~$ openssl speed blowfish des rc2 idea rc4 rc5
...
BlowFish s'en sort plutôt bien; je n'ai pas d'AES sur cette version
d'OpenSSL (et peut-être que toi non plus), mais par design AES est plus
rapide que Blowfish (pour un même effort d'optimisation, bien entendu);
RC4 est de très loin le plus rapide (et c'est normal, quand on sait
comment ça marche). Blowfish a également un problème à l'initialisation de
la clé, c'est de très loin le plus lent de tous dans ce cas (ça n'est pas
indiqué ici), ça *peut* avoir un impact lors d'un grand nombre de
connexions.
Les flags utilisés pour compiler OpenSSL peuvent donner de sérieuses
différences en terme de perfs (plus que pour d'autres applis
'classiques').
Bonjour,
On Sat, 10 Jan 2004, no_spam wrote:On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:On Fri, 9 Jan 2004, no_spam wrote:On Fri, 09 Jan 2004 13:42:18 +0100, El NiKo wrote:
Je ne l'utilise pas comme routeur/firewall pour deux raisons:
- il plafonne à 1 Mbit/s en cryptage SSH (avec blowfish), ce qui
est un peu léger.
Oublie Blowfish, prend AES (s'il est dispo sur ton serveur et ton
client). C'est plus rapide, c'est le standard, ça a été bien analysé.
Ou alors tu préfères le risque, et tu prends arcfour (RC4). C'est
*nettement* plus rapide, et ça tient la route si c'est bien utilisé (c'est
généralement là le problème).
J'ai essayé tous les cypher que ssh me présentait, et blowfish était
le plus rapide.
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
-----
:~$ openssl speed blowfish des rc2 idea rc4 rc5
...
BlowFish s'en sort plutôt bien; je n'ai pas d'AES sur cette version
d'OpenSSL (et peut-être que toi non plus), mais par design AES est plus
rapide que Blowfish (pour un même effort d'optimisation, bien entendu);
RC4 est de très loin le plus rapide (et c'est normal, quand on sait
comment ça marche). Blowfish a également un problème à l'initialisation de
la clé, c'est de très loin le plus lent de tous dans ce cas (ça n'est pas
indiqué ici), ça *peut* avoir un impact lors d'un grand nombre de
connexions.
Les flags utilisés pour compiler OpenSSL peuvent donner de sérieuses
différences en terme de perfs (plus que pour d'autres applis
'classiques').
On Sun, 11 Jan 2004 17:26:46 +0100, Erwann ABALEA wrote:On Sat, 10 Jan 2004, no_spam wrote:On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
Enfin, il utilise les algo d'Openssl, mais pas le protocole:
il se sert en fait uniquement de la libcrypto
:~$ openssl speed blowfish des rc2 idea rc4 rc5
...BlowFish s'en sort plutôt bien; je n'ai pas d'AES sur cette version
d'OpenSSL (et peut-être que toi non plus), mais par design AES est plus
rapide que Blowfish (pour un même effort d'optimisation, bien entendu);
RC4 est de très loin le plus rapide (et c'est normal, quand on sait
comment ça marche). Blowfish a également un problème à l'initialisation de
la clé, c'est de très loin le plus lent de tous dans ce cas (ça n'est pas
indiqué ici), ça *peut* avoir un impact lors d'un grand nombre de
connexions.
RC2, RC5 et idea ne sont pas disponibles pour ssh.
En effet, ils sont brevetés, et donc l'équipe d'openssh ne veut
pas les implémenter.
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Il semble que openssh utilise peu d'algorithmes de la libcrypto,
peut-être uniquement les hash et les digests...
En effet, ma version d'openssl ne supporte ni l'arcfour, ni l'aes
et pourtant ssh me les propose...
Le test que j'ai fait est le suivant:
scp /tmp/mem/random 127.0.0.1:/tmp/mem/random2
Ca copie de la RAM vers la RAM...
[... résultats, avec le tiercé dans l'ordre: BF, CAST, DES, puis seulement
J'ai essayé de trouver des benchs via Google.
Apparement, aes128 donne à peu près les mêmes performances
que blowfish. Mais il est fort possible que, comme tu le soulignes,
les implémentations d'AES ne soient pas encore bien optimisées.
J'ai fait un test du même genre avec gpg (qui a sa propre implémentation
des ciphers).
Ca donne:
[... les résultats, et cette fois les gagnants sont: CAST, AES, BF ...]
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
On Sun, 11 Jan 2004 17:26:46 +0100, Erwann ABALEA wrote:
On Sat, 10 Jan 2004, no_spam wrote:
On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
Enfin, il utilise les algo d'Openssl, mais pas le protocole:
il se sert en fait uniquement de la libcrypto
eabalea@shining:~$ openssl speed blowfish des rc2 idea rc4 rc5
...
BlowFish s'en sort plutôt bien; je n'ai pas d'AES sur cette version
d'OpenSSL (et peut-être que toi non plus), mais par design AES est plus
rapide que Blowfish (pour un même effort d'optimisation, bien entendu);
RC4 est de très loin le plus rapide (et c'est normal, quand on sait
comment ça marche). Blowfish a également un problème à l'initialisation de
la clé, c'est de très loin le plus lent de tous dans ce cas (ça n'est pas
indiqué ici), ça *peut* avoir un impact lors d'un grand nombre de
connexions.
RC2, RC5 et idea ne sont pas disponibles pour ssh.
En effet, ils sont brevetés, et donc l'équipe d'openssh ne veut
pas les implémenter.
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Il semble que openssh utilise peu d'algorithmes de la libcrypto,
peut-être uniquement les hash et les digests...
En effet, ma version d'openssl ne supporte ni l'arcfour, ni l'aes
et pourtant ssh me les propose...
Le test que j'ai fait est le suivant:
scp /tmp/mem/random 127.0.0.1:/tmp/mem/random2
Ca copie de la RAM vers la RAM...
[... résultats, avec le tiercé dans l'ordre: BF, CAST, DES, puis seulement
J'ai essayé de trouver des benchs via Google.
Apparement, aes128 donne à peu près les mêmes performances
que blowfish. Mais il est fort possible que, comme tu le soulignes,
les implémentations d'AES ne soient pas encore bien optimisées.
J'ai fait un test du même genre avec gpg (qui a sa propre implémentation
des ciphers).
Ca donne:
[... les résultats, et cette fois les gagnants sont: CAST, AES, BF ...]
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
On Sun, 11 Jan 2004 17:26:46 +0100, Erwann ABALEA wrote:On Sat, 10 Jan 2004, no_spam wrote:On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
Enfin, il utilise les algo d'Openssl, mais pas le protocole:
il se sert en fait uniquement de la libcrypto
:~$ openssl speed blowfish des rc2 idea rc4 rc5
...BlowFish s'en sort plutôt bien; je n'ai pas d'AES sur cette version
d'OpenSSL (et peut-être que toi non plus), mais par design AES est plus
rapide que Blowfish (pour un même effort d'optimisation, bien entendu);
RC4 est de très loin le plus rapide (et c'est normal, quand on sait
comment ça marche). Blowfish a également un problème à l'initialisation de
la clé, c'est de très loin le plus lent de tous dans ce cas (ça n'est pas
indiqué ici), ça *peut* avoir un impact lors d'un grand nombre de
connexions.
RC2, RC5 et idea ne sont pas disponibles pour ssh.
En effet, ils sont brevetés, et donc l'équipe d'openssh ne veut
pas les implémenter.
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Il semble que openssh utilise peu d'algorithmes de la libcrypto,
peut-être uniquement les hash et les digests...
En effet, ma version d'openssl ne supporte ni l'arcfour, ni l'aes
et pourtant ssh me les propose...
Le test que j'ai fait est le suivant:
scp /tmp/mem/random 127.0.0.1:/tmp/mem/random2
Ca copie de la RAM vers la RAM...
[... résultats, avec le tiercé dans l'ordre: BF, CAST, DES, puis seulement
J'ai essayé de trouver des benchs via Google.
Apparement, aes128 donne à peu près les mêmes performances
que blowfish. Mais il est fort possible que, comme tu le soulignes,
les implémentations d'AES ne soient pas encore bien optimisées.
J'ai fait un test du même genre avec gpg (qui a sa propre implémentation
des ciphers).
Ca donne:
[... les résultats, et cette fois les gagnants sont: CAST, AES, BF ...]
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Bonjour,
On Sun, 11 Jan 2004, no_spam wrote:On Sun, 11 Jan 2004 17:26:46 +0100, Erwann ABALEA wrote:On Sat, 10 Jan 2004, no_spam wrote:On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
Enfin, il utilise les algo d'Openssl, mais pas le protocole:
il se sert en fait uniquement de la libcrypto
Oui, je suis quand même au courant... (je fais de la crypto toute la
journée) ;)
En effet, ils sont brevetés, et donc l'équipe d'openssh ne veut
pas les implémenter.
Concernant IDEA, ce brevet n'est valable qu'en Europe, et je crois savoir
qu'ASCOM permet une utilisation non commerciale de l'algo.
RC4 est toujours considéré comme un 'trade secret', comme RC2, et il est
quand même disponible par défaut. Il n'y a aucun brevet sur RC2 et RC4,
seuls les noms "RC2" et "RC4" appartiennent à RSA (c'est pour ça que les
implémentations libres de RC4 s'appellent ARC4 ou arcfour).
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
Il semble que openssh utilise peu d'algorithmes de la libcrypto,
peut-être uniquement les hash et les digests...
En effet, ma version d'openssl ne supporte ni l'arcfour, ni l'aes
M'étonnerait. arcfour = RC4. :)
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
Bonjour,
On Sun, 11 Jan 2004, no_spam wrote:
On Sun, 11 Jan 2004 17:26:46 +0100, Erwann ABALEA wrote:
On Sat, 10 Jan 2004, no_spam wrote:
On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
Enfin, il utilise les algo d'Openssl, mais pas le protocole:
il se sert en fait uniquement de la libcrypto
Oui, je suis quand même au courant... (je fais de la crypto toute la
journée) ;)
En effet, ils sont brevetés, et donc l'équipe d'openssh ne veut
pas les implémenter.
Concernant IDEA, ce brevet n'est valable qu'en Europe, et je crois savoir
qu'ASCOM permet une utilisation non commerciale de l'algo.
RC4 est toujours considéré comme un 'trade secret', comme RC2, et il est
quand même disponible par défaut. Il n'y a aucun brevet sur RC2 et RC4,
seuls les noms "RC2" et "RC4" appartiennent à RSA (c'est pour ça que les
implémentations libres de RC4 s'appellent ARC4 ou arcfour).
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
Il semble que openssh utilise peu d'algorithmes de la libcrypto,
peut-être uniquement les hash et les digests...
En effet, ma version d'openssl ne supporte ni l'arcfour, ni l'aes
M'étonnerait. arcfour = RC4. :)
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
Bonjour,
On Sun, 11 Jan 2004, no_spam wrote:On Sun, 11 Jan 2004 17:26:46 +0100, Erwann ABALEA wrote:On Sat, 10 Jan 2004, no_spam wrote:On Sat, 10 Jan 2004 00:36:20 +0100, Erwann ABALEA wrote:
Là, tu m'étonnes... OpenSSH utilise OpenSSL, et voici les perfs que me
donne OpenSSL sur mon U2 à 300 MHz:
Enfin, il utilise les algo d'Openssl, mais pas le protocole:
il se sert en fait uniquement de la libcrypto
Oui, je suis quand même au courant... (je fais de la crypto toute la
journée) ;)
En effet, ils sont brevetés, et donc l'équipe d'openssh ne veut
pas les implémenter.
Concernant IDEA, ce brevet n'est valable qu'en Europe, et je crois savoir
qu'ASCOM permet une utilisation non commerciale de l'algo.
RC4 est toujours considéré comme un 'trade secret', comme RC2, et il est
quand même disponible par défaut. Il n'y a aucun brevet sur RC2 et RC4,
seuls les noms "RC2" et "RC4" appartiennent à RSA (c'est pour ça que les
implémentations libres de RC4 s'appellent ARC4 ou arcfour).
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
Il semble que openssh utilise peu d'algorithmes de la libcrypto,
peut-être uniquement les hash et les digests...
En effet, ma version d'openssl ne supporte ni l'arcfour, ni l'aes
M'étonnerait. arcfour = RC4. :)
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
On Mon, 12 Jan 2004 18:46:20 +0100, Erwann ABALEA wrote:Oui, je suis quand même au courant... (je fais de la crypto toute la
journée) ;)
Faut pas que je dises trop de conneries, alors :-)
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
J'ai sans doute un a-priori sur RC4, quand je vois la faiblesse
du WEP. Je n'ai pas la compétence pour dire pourquoi le WEP est faible,
mais je l'ai constaté à plus d'une reprise (intrusions sur mes
réseaux Wifi de test au boulot, utilisant des clés 128 bits et
passant peu de trafic...).
Quand au RC2, je me fie à ce que m'ont
dit des "dinosaures" de l'informatique embarquée, mais il ne sont
pas, à ce que je sache, des gourous de la crypto.
M'étonnerait. arcfour = RC4. :)
Vi, je me suis emmelé les pinceaux, sur ce coup là (j'ai surtout
pas relu avant de poster) J'espérait que ça ne se verrait pas
de trop :-)
...Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
J'ai besoin, entre autres, de crypter/decrytper en temps réel
tout ce qui passe "légalement" sur l'interface Wifi...
Ce qui me conduit à vouloir crypter et decrypter simultanément
jusqu'à 11 Mb/s, ce que ne fait pas mon 68040...
A 21 cycles par octets, il devrait s'en approcher...
J'ai récupéré un PPC additionnel, je peux peut-être m'en servir
comme coprocesseur cryptographique :-)
On Mon, 12 Jan 2004 18:46:20 +0100, Erwann ABALEA wrote:
Oui, je suis quand même au courant... (je fais de la crypto toute la
journée) ;)
Faut pas que je dises trop de conneries, alors :-)
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
J'ai sans doute un a-priori sur RC4, quand je vois la faiblesse
du WEP. Je n'ai pas la compétence pour dire pourquoi le WEP est faible,
mais je l'ai constaté à plus d'une reprise (intrusions sur mes
réseaux Wifi de test au boulot, utilisant des clés 128 bits et
passant peu de trafic...).
Quand au RC2, je me fie à ce que m'ont
dit des "dinosaures" de l'informatique embarquée, mais il ne sont
pas, à ce que je sache, des gourous de la crypto.
M'étonnerait. arcfour = RC4. :)
Vi, je me suis emmelé les pinceaux, sur ce coup là (j'ai surtout
pas relu avant de poster) J'espérait que ça ne se verrait pas
de trop :-)
...
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
J'ai besoin, entre autres, de crypter/decrytper en temps réel
tout ce qui passe "légalement" sur l'interface Wifi...
Ce qui me conduit à vouloir crypter et decrypter simultanément
jusqu'à 11 Mb/s, ce que ne fait pas mon 68040...
A 21 cycles par octets, il devrait s'en approcher...
J'ai récupéré un PPC additionnel, je peux peut-être m'en servir
comme coprocesseur cryptographique :-)
On Mon, 12 Jan 2004 18:46:20 +0100, Erwann ABALEA wrote:Oui, je suis quand même au courant... (je fais de la crypto toute la
journée) ;)
Faut pas que je dises trop de conneries, alors :-)
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
J'ai sans doute un a-priori sur RC4, quand je vois la faiblesse
du WEP. Je n'ai pas la compétence pour dire pourquoi le WEP est faible,
mais je l'ai constaté à plus d'une reprise (intrusions sur mes
réseaux Wifi de test au boulot, utilisant des clés 128 bits et
passant peu de trafic...).
Quand au RC2, je me fie à ce que m'ont
dit des "dinosaures" de l'informatique embarquée, mais il ne sont
pas, à ce que je sache, des gourous de la crypto.
M'étonnerait. arcfour = RC4. :)
Vi, je me suis emmelé les pinceaux, sur ce coup là (j'ai surtout
pas relu avant de poster) J'espérait que ça ne se verrait pas
de trop :-)
...Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
J'ai besoin, entre autres, de crypter/decrytper en temps réel
tout ce qui passe "légalement" sur l'interface Wifi...
Ce qui me conduit à vouloir crypter et decrypter simultanément
jusqu'à 11 Mb/s, ce que ne fait pas mon 68040...
A 21 cycles par octets, il devrait s'en approcher...
J'ai récupéré un PPC additionnel, je peux peut-être m'en servir
comme coprocesseur cryptographique :-)
Bonsoir,
On Mon, 12 Jan 2004, no_spam wrote:De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
J'ai sans doute un a-priori sur RC4, quand je vois la faiblesse
du WEP. Je n'ai pas la compétence pour dire pourquoi le WEP est faible,
mais je l'ai constaté à plus d'une reprise (intrusions sur mes
réseaux Wifi de test au boulot, utilisant des clés 128 bits et
passant peu de trafic...).
Je n'ai pas assez mis en évidence le "tant qu'il est utilisé
correctement". En effet, il est très facile d'utiliser RC4 de manière à
ouvrir des failles. Une bonne règle à respecter avec cet algo est qu'il
faut 'jeter' les 256 premiers octets du flux pseudo-aléatoire généré. Une
règle commune à tous les système de chiffrement de flux (classe à laquelle
fait partie RC4) est qu'il faut *absolument* éviter de chiffrer 2 clairs
avec la même clé. Dans le cas d'un réseau, il faut donc:
- soit chiffrer chaque bloc avec une clé différente (négociée à l'avance
selon un algo précis)
- soit continuer à chiffrer les blocs avec l'état interne courant du
cryptosystème, sans le réinitialiser (i.e. faire comme si le paquet est
la suite logique des paquets précédents, éventuellement en fixant des
points de renégociation réguliers)
Si on ne fait pas ça, alors l'attaquant n'a plus qu'à prendre 2 flux
chiffrés avec la même clé, faire un XOR entre les 2, et il aura le
résultat d'un XOR entre les 2 flux en clair, et la clé aura disparu,
miraculeusement.
Les attaques du WEP concernent:
- la génération des clés (le générateur de pseudo-aléa est le point
faible de beaucoup d'implémentations)
- l'utilisation de ces clés (je trouve ignoble qu'on arrive à transmettre
24 bits de la clé en clair dans chaque paquet)
Quand au RC2, je me fie à ce que m'ont
dit des "dinosaures" de l'informatique embarquée, mais il ne sont
pas, à ce que je sache, des gourous de la crypto.
A ma connaissance, il n'existe pas d'attaque fulgurante contre RC2, juste
l'analyse différentielle, qui permet une attaque en 2^60 environ (cela
signifie qu'il faut être capable de chiffrer et stocker 2^60 blocs de 8
octets choisis avec le chiffré correspondant, avec la même clé, avant de
pouvoir trouver cette clé, ce qui représente 16777216 To de stockage).
Académiquement, c'est une faiblesse, mais en pratique, ça ne gène pas
grand monde.
Si tes dinos font de l'embarqué, alors ils ont peut-être abandonné RC2 à
cause de sa lenteur. Même un DES (optimisé) est plus rapide que RC2. S'ils
ont voulu gagner en perfs en réduisant le nombre de rondes de RC2, alors
ils l'ont affaibli, et c'est pas bien. ;)
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
Probablement pas cette implémentation là, Christophe Devine la vend (c'est
du boulot, ça se rémunère). Et ce Mr Devine est français, pour une fois.
;)
J'ai besoin, entre autres, de crypter/decrytper en temps réel
tout ce qui passe "légalement" sur l'interface Wifi...
Ce qui me conduit à vouloir crypter et decrypter simultanément
jusqu'à 11 Mb/s, ce que ne fait pas mon 68040...
Il tourne à quelle vitesse ton 68040? C'est un vieux Mac que tu as?
A 21 cycles par octets, il devrait s'en approcher...
C'est pour un P4. Pour d'autres processeurs, le ratio sera différent.
J'ai récupéré un PPC additionnel, je peux peut-être m'en servir
comme coprocesseur cryptographique :-)
Luxe... ;)
Bonsoir,
On Mon, 12 Jan 2004, no_spam wrote:
De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
J'ai sans doute un a-priori sur RC4, quand je vois la faiblesse
du WEP. Je n'ai pas la compétence pour dire pourquoi le WEP est faible,
mais je l'ai constaté à plus d'une reprise (intrusions sur mes
réseaux Wifi de test au boulot, utilisant des clés 128 bits et
passant peu de trafic...).
Je n'ai pas assez mis en évidence le "tant qu'il est utilisé
correctement". En effet, il est très facile d'utiliser RC4 de manière à
ouvrir des failles. Une bonne règle à respecter avec cet algo est qu'il
faut 'jeter' les 256 premiers octets du flux pseudo-aléatoire généré. Une
règle commune à tous les système de chiffrement de flux (classe à laquelle
fait partie RC4) est qu'il faut *absolument* éviter de chiffrer 2 clairs
avec la même clé. Dans le cas d'un réseau, il faut donc:
- soit chiffrer chaque bloc avec une clé différente (négociée à l'avance
selon un algo précis)
- soit continuer à chiffrer les blocs avec l'état interne courant du
cryptosystème, sans le réinitialiser (i.e. faire comme si le paquet est
la suite logique des paquets précédents, éventuellement en fixant des
points de renégociation réguliers)
Si on ne fait pas ça, alors l'attaquant n'a plus qu'à prendre 2 flux
chiffrés avec la même clé, faire un XOR entre les 2, et il aura le
résultat d'un XOR entre les 2 flux en clair, et la clé aura disparu,
miraculeusement.
Les attaques du WEP concernent:
- la génération des clés (le générateur de pseudo-aléa est le point
faible de beaucoup d'implémentations)
- l'utilisation de ces clés (je trouve ignoble qu'on arrive à transmettre
24 bits de la clé en clair dans chaque paquet)
Quand au RC2, je me fie à ce que m'ont
dit des "dinosaures" de l'informatique embarquée, mais il ne sont
pas, à ce que je sache, des gourous de la crypto.
A ma connaissance, il n'existe pas d'attaque fulgurante contre RC2, juste
l'analyse différentielle, qui permet une attaque en 2^60 environ (cela
signifie qu'il faut être capable de chiffrer et stocker 2^60 blocs de 8
octets choisis avec le chiffré correspondant, avec la même clé, avant de
pouvoir trouver cette clé, ce qui représente 16777216 To de stockage).
Académiquement, c'est une faiblesse, mais en pratique, ça ne gène pas
grand monde.
Si tes dinos font de l'embarqué, alors ils ont peut-être abandonné RC2 à
cause de sa lenteur. Même un DES (optimisé) est plus rapide que RC2. S'ils
ont voulu gagner en perfs en réduisant le nombre de rondes de RC2, alors
ils l'ont affaibli, et c'est pas bien. ;)
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
Probablement pas cette implémentation là, Christophe Devine la vend (c'est
du boulot, ça se rémunère). Et ce Mr Devine est français, pour une fois.
;)
J'ai besoin, entre autres, de crypter/decrytper en temps réel
tout ce qui passe "légalement" sur l'interface Wifi...
Ce qui me conduit à vouloir crypter et decrypter simultanément
jusqu'à 11 Mb/s, ce que ne fait pas mon 68040...
Il tourne à quelle vitesse ton 68040? C'est un vieux Mac que tu as?
A 21 cycles par octets, il devrait s'en approcher...
C'est pour un P4. Pour d'autres processeurs, le ratio sera différent.
J'ai récupéré un PPC additionnel, je peux peut-être m'en servir
comme coprocesseur cryptographique :-)
Luxe... ;)
Bonsoir,
On Mon, 12 Jan 2004, no_spam wrote:De plus, RC2 et RC4 sont trop faibles pour être
utilisés pour un cryptage sérieux !
Faux, faux et archi-faux. RC4 est toujours considéré comme fiable, tant
qu'il est utilisé correctement, ce qui est le cas par exemple pour le
protocole SSL/TLS. RC4 est de loin l'algo le plus utilisé pour le
chiffrement dans une session SSL, et il est utilisé dans pas mal d'autres
produits, pour sa simplicité, ses performances, et sa sécurité. Je ne
pense pas que RC2 ait été cassé, mais il n'est pas tellement utilisé et
est resté secret plus longtemps que RC2, donc il n'intéresse pas grand
monde.
J'ai sans doute un a-priori sur RC4, quand je vois la faiblesse
du WEP. Je n'ai pas la compétence pour dire pourquoi le WEP est faible,
mais je l'ai constaté à plus d'une reprise (intrusions sur mes
réseaux Wifi de test au boulot, utilisant des clés 128 bits et
passant peu de trafic...).
Je n'ai pas assez mis en évidence le "tant qu'il est utilisé
correctement". En effet, il est très facile d'utiliser RC4 de manière à
ouvrir des failles. Une bonne règle à respecter avec cet algo est qu'il
faut 'jeter' les 256 premiers octets du flux pseudo-aléatoire généré. Une
règle commune à tous les système de chiffrement de flux (classe à laquelle
fait partie RC4) est qu'il faut *absolument* éviter de chiffrer 2 clairs
avec la même clé. Dans le cas d'un réseau, il faut donc:
- soit chiffrer chaque bloc avec une clé différente (négociée à l'avance
selon un algo précis)
- soit continuer à chiffrer les blocs avec l'état interne courant du
cryptosystème, sans le réinitialiser (i.e. faire comme si le paquet est
la suite logique des paquets précédents, éventuellement en fixant des
points de renégociation réguliers)
Si on ne fait pas ça, alors l'attaquant n'a plus qu'à prendre 2 flux
chiffrés avec la même clé, faire un XOR entre les 2, et il aura le
résultat d'un XOR entre les 2 flux en clair, et la clé aura disparu,
miraculeusement.
Les attaques du WEP concernent:
- la génération des clés (le générateur de pseudo-aléa est le point
faible de beaucoup d'implémentations)
- l'utilisation de ces clés (je trouve ignoble qu'on arrive à transmettre
24 bits de la clé en clair dans chaque paquet)
Quand au RC2, je me fie à ce que m'ont
dit des "dinosaures" de l'informatique embarquée, mais il ne sont
pas, à ce que je sache, des gourous de la crypto.
A ma connaissance, il n'existe pas d'attaque fulgurante contre RC2, juste
l'analyse différentielle, qui permet une attaque en 2^60 environ (cela
signifie qu'il faut être capable de chiffrer et stocker 2^60 blocs de 8
octets choisis avec le chiffré correspondant, avec la même clé, avant de
pouvoir trouver cette clé, ce qui représente 16777216 To de stockage).
Académiquement, c'est une faiblesse, mais en pratique, ça ne gène pas
grand monde.
Si tes dinos font de l'embarqué, alors ils ont peut-être abandonné RC2 à
cause de sa lenteur. Même un DES (optimisé) est plus rapide que RC2. S'ils
ont voulu gagner en perfs en réduisant le nombre de rondes de RC2, alors
ils l'ont affaibli, et c'est pas bien. ;)
Bien sur, les deux tests ne sont pas comparables, puisque dans un cas
on ne fait que crypter et dans le cas du scp, je decrypte aussi.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
Probablement pas cette implémentation là, Christophe Devine la vend (c'est
du boulot, ça se rémunère). Et ce Mr Devine est français, pour une fois.
;)
J'ai besoin, entre autres, de crypter/decrytper en temps réel
tout ce qui passe "légalement" sur l'interface Wifi...
Ce qui me conduit à vouloir crypter et decrypter simultanément
jusqu'à 11 Mb/s, ce que ne fait pas mon 68040...
Il tourne à quelle vitesse ton 68040? C'est un vieux Mac que tu as?
A 21 cycles par octets, il devrait s'en approcher...
C'est pour un P4. Pour d'autres processeurs, le ratio sera différent.
J'ai récupéré un PPC additionnel, je peux peut-être m'en servir
comme coprocesseur cryptographique :-)
Luxe... ;)
disait...
j'ai un P166 avec 32M Ram (avec un DD de 1Go mais bon ca peut se
changer) et je cherche desesperement la maniere de le recycler ( oui
par nostalgie)
J'ai utilisé ce type de config sans soucis avec RH6.2, ou une slack?
Oublie X-window, bien sûr, mais sinon ça tourne très bien.
En plus, question "self esteem", Linux, c'est autre chose ("yeah, j'ai
réussi à compiler un noyau !"
Moi je le fais faire par gcc -+- MB in GLP "bien configurer son égo" -+-
EnleverNickLeeSpam@free.fr disait...
j'ai un P166 avec 32M Ram (avec un DD de 1Go mais bon ca peut se
changer) et je cherche desesperement la maniere de le recycler ( oui
par nostalgie)
J'ai utilisé ce type de config sans soucis avec RH6.2, ou une slack?
Oublie X-window, bien sûr, mais sinon ça tourne très bien.
En plus, question "self esteem", Linux, c'est autre chose ("yeah, j'ai
réussi à compiler un noyau !"
Moi je le fais faire par gcc -+- MB in GLP "bien configurer son égo" -+-
disait...
j'ai un P166 avec 32M Ram (avec un DD de 1Go mais bon ca peut se
changer) et je cherche desesperement la maniere de le recycler ( oui
par nostalgie)
J'ai utilisé ce type de config sans soucis avec RH6.2, ou une slack?
Oublie X-window, bien sûr, mais sinon ça tourne très bien.
En plus, question "self esteem", Linux, c'est autre chose ("yeah, j'ai
réussi à compiler un noyau !"
Moi je le fais faire par gcc -+- MB in GLP "bien configurer son égo" -+-
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
Probablement pas cette implémentation là, Christophe Devine la vend (c'est
du boulot, ça se rémunère). Et ce Mr Devine est français, pour une fois.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
Probablement pas cette implémentation là, Christophe Devine la vend (c'est
du boulot, ça se rémunère). Et ce Mr Devine est français, pour une fois.
Et certains algos chiffrent et déchiffrent à des vitesses différentes, ce
qui est le cas de l'AES par exemple, et pas du DES. L'AES peut chiffrer et
déchiffrer à la même vitesse, si on le souhaite (ça dépend des
optimisations). C'est le cas de l'implémentation à 21 cycles par octet
dont je cause plus haut.
J'éspère qu'elle sera disponible pour ssh rapidement :-)
Probablement pas cette implémentation là, Christophe Devine la vend (c'est
du boulot, ça se rémunère). Et ce Mr Devine est français, pour une fois.
