Skype chiffrement
Le
thehermes
Bonjour a tous,
Voila je me pose une petite question concernant le chiffrement
effectue par le logiciel de communication Skype. Il est dit que
celui-ci utilise un chiffrement symetrique AES avec un etablissement
de session a l'aide d'un chiffrement asymetrique RSA (pour permettre
l'echange de la clef secrete). Ce qui m'interesse c'est surtout la
partie concernant le chiffrement symetrique. Ce logiciel etant un
logiciel de communication temps reel notamment audio, on ne connaît
normalement pas la taille de ce qu'il y a a envoyer a l'avance. Donc
en fait je vois pas trop comment il font pour pratiquer un chiffrement
a l'aide de l'algo AES (Rijndael) qui est un algo de chiffrement par
bloc. A moins qu'ils utilisent le mode Cipher FeedBack (CFB) qui
pourrait permettre de chiffrer bit a bit mais l'interet du chiffrement
par bloc serait alors plus que reduit (calculs inutiles) et un
chiffrement par flot (stream cipher) serait alors plus approprie.
C'est pour cela que je me demande pourquoi ils ont utilise un
chiffrement par bloc au lieu d'un chiffrement par flot. A moins qu'ils
utilisent une technique de cache ou buffer qui attend d'avoir engrange
assez de donnes pour avoir un bloc de taille souhaite.
Voila qu'en pensez vous. De tout facon leur technique marche donc
c'est que cela doit etre possible d'une maniere ou d'une autre. Si
quelqu'un pouvait m'eclairer de son point de vu sur ce sujet
Sinon question annexe j'ai lu sur un site (www.securiteinfo.com) pour
ne pas le citer que les algo symetriques de chiffrement par flot sont
plus faibles en terme de securite que les algos de chiffrement par
bloc. Qu'en pensez vous car on m'avait dit que les deux etaient
kif-kif mais qu'ils n'etaient pas utilise dans les meme conditions (cf
ma question precedente). On dit souvent que les chiffre par flot
utilisent moins de ressources que leur homologues block cipher.
Donc si vous pouviez m'eclairer un peut sur ce point concernant donc
la securite des deux types de solutions, j'en serais tres heureux.
Merci.
Voila je me pose une petite question concernant le chiffrement
effectue par le logiciel de communication Skype. Il est dit que
celui-ci utilise un chiffrement symetrique AES avec un etablissement
de session a l'aide d'un chiffrement asymetrique RSA (pour permettre
l'echange de la clef secrete). Ce qui m'interesse c'est surtout la
partie concernant le chiffrement symetrique. Ce logiciel etant un
logiciel de communication temps reel notamment audio, on ne connaît
normalement pas la taille de ce qu'il y a a envoyer a l'avance. Donc
en fait je vois pas trop comment il font pour pratiquer un chiffrement
a l'aide de l'algo AES (Rijndael) qui est un algo de chiffrement par
bloc. A moins qu'ils utilisent le mode Cipher FeedBack (CFB) qui
pourrait permettre de chiffrer bit a bit mais l'interet du chiffrement
par bloc serait alors plus que reduit (calculs inutiles) et un
chiffrement par flot (stream cipher) serait alors plus approprie.
C'est pour cela que je me demande pourquoi ils ont utilise un
chiffrement par bloc au lieu d'un chiffrement par flot. A moins qu'ils
utilisent une technique de cache ou buffer qui attend d'avoir engrange
assez de donnes pour avoir un bloc de taille souhaite.
Voila qu'en pensez vous. De tout facon leur technique marche donc
c'est que cela doit etre possible d'une maniere ou d'une autre. Si
quelqu'un pouvait m'eclairer de son point de vu sur ce sujet
Sinon question annexe j'ai lu sur un site (www.securiteinfo.com) pour
ne pas le citer que les algo symetriques de chiffrement par flot sont
plus faibles en terme de securite que les algos de chiffrement par
bloc. Qu'en pensez vous car on m'avait dit que les deux etaient
kif-kif mais qu'ils n'etaient pas utilise dans les meme conditions (cf
ma question precedente). On dit souvent que les chiffre par flot
utilisent moins de ressources que leur homologues block cipher.
Donc si vous pouviez m'eclairer un peut sur ce point concernant donc
la securite des deux types de solutions, j'en serais tres heureux.
Merci.
Poser une question
bein oui, forcément. skype utilise de la voix paquetisée. Il attend
suffisamment longtemps jusqu'à avoir des données d'une taille
raisonnable avant de les envoyer. Sinon vous imaginez quoi ? il envoie
un paquet de la taille d'un échantillon ?? un paquet IP de 20 octets
d'entête pour seulement un octet de données ? (et même moins parce que
ça doit être du compressé ;) )
Qu'il fasse du padding par exemple ?
--
printk("; corrupted filesystem mounted read/write - your computer
will explode within 20 seconds ... but you wanted it so!n");
2.4.3 linux/fs/hpfs/super.c
pour avoir des données d'une taille proportionnelle à la taille des
blocs dont il a besoin, et cet effet doit être negligeable (tout doit
être fait pour éviter de faire du bourrage). Le bourrage n'a aucun
interrêt d'un point de vue efficacité réseau (avant de s'occupuer des
aspects sécurité, faut peut-être avoir un protocole qui marche ;) ) de
mettre un octet de données utiles + 15 octets de bourrage ( si AES
utilise des blocs de 128bits) + 20 octets entête IP + 8 UDP... (je dis
ça comme ça, dans un cadre général de VoIP, je sais pas exactement quel
sont les protocoles vraiment mis par skype) L'efficacite est de 1/44 !!!
Si on attend un peu plus longtemps, et en faisant tout pour éviter le
bourrage, l'efficacité devient de 16/44, 16 fois mieux!!! Ceci est dit,
ça va ajouter de la latence dans la communication, mais je vous assure
que c'est beaucoup moins important que toutes les latences ajoutées par
tout les routeurs parlesquels le message passe :)
Amine,
Ils ne peuvent pas résoudre ce problème en cachant
car s'il n'y a plus de données qui arrivent ils sont bien obligés de faire
quelque chose.
Il ne me semble pas que Skype communique sur le mode utilisé. Il y a
cependant
fort à parier qu'il utilisent un des deux modes suivants:
- soit CBC et dans ce cas ils paddent pour arriver à une taille
multiple de la taille du bloc.
- soit le mode CTR, et dans ce cas on a un stream cipher et plus de problème
de padding.
Ces deux méthodes sont actuellement les deux modes les plus courants
d'utilisation
des algos de chiffrement par bloc dans les réseaux. Le deuxième, CTR, a été
redécouvert
(il avait été inventé par Diffie en 1979!) et est de plus en plus utilisé
depuis
qu'il a été standardisé en 2001.
Le problème des stream cipher est qu'il y en a peu et qu'il y a eu
infiniment
moins de recherche effectuée sur les stream cipher que sur les block
ciphers.
On a donc tendance à avoir moins confiance en eux. Un autre problème est
qu'aucun
stream cipher existant n'a été standardisé par le NIST. On préfère
généralement
ainsi utiliser un block cipher avec un mode d'utilisation en stream cipher
(comme CTR).
Olivier Gay
http://www.ouah.org
Ouha!!
Aaah, ok, j'ai compris! Ouha!