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.
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
Amine Elleuch
Bonjour a tous,
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.
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é ;) )
Bonjour a tous,
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.
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é ;) )
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.
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é ;) )
Cedric Blancher
Le Fri, 08 Apr 2005 09:21:16 +0200, Amine Elleuch a écrit :
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 ?
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
Le Fri, 08 Apr 2005 09:21:16 +0200, Amine Elleuch a écrit :
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 ?
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
Le Fri, 08 Apr 2005 09:21:16 +0200, Amine Elleuch a écrit :
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 ?
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
Amine Elleuch
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 ?
Qu'il fasse du padding par exemple ?
eeee, oui, peut-être qu'il utilise un peu de padding, mais uniquement
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,
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 ?
Qu'il fasse du padding par exemple ?
eeee, oui, peut-être qu'il utilise un peu de padding, mais uniquement
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 :)
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 ?
Qu'il fasse du padding par exemple ?
eeee, oui, peut-être qu'il utilise un peu de padding, mais uniquement
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,
OUAH
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.
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
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.
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).
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.
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).
Voila je me pose une petite question concernant le chiffrement effectue par le logiciel de communication Skype. Il est dit que
N'oublions pas la problèmatique de perte de paquets. Un protocole de voix ou vidéo sur IP, style RTSP,doitc être capable de perdre ou de mélanger des paquets. Ca supporte ça un protocole de chiffrement en flux (stream cipher) ? -- www.castalie.fr
On 7 Apr 2005 17:26:18 -0700, thehermes@altern.org (yu) wrote:
Bonjour a tous,
Voila je me pose une petite question concernant le chiffrement
effectue par le logiciel de communication Skype. Il est dit que
N'oublions pas la problèmatique de perte de paquets. Un protocole de
voix ou vidéo sur IP, style RTSP,doitc être capable de perdre ou de
mélanger des paquets. Ca supporte ça un protocole de chiffrement en
flux (stream cipher) ?
--
www.castalie.fr
Voila je me pose une petite question concernant le chiffrement effectue par le logiciel de communication Skype. Il est dit que
N'oublions pas la problèmatique de perte de paquets. Un protocole de voix ou vidéo sur IP, style RTSP,doitc être capable de perdre ou de mélanger des paquets. Ca supporte ça un protocole de chiffrement en flux (stream cipher) ? -- www.castalie.fr
Erwann ABALEA
Bonjour,
On Fri, 8 Apr 2005, Fabrice Bacchella wrote:
On 7 Apr 2005 17:26:18 -0700, (yu) wrote:
N'oublions pas la problèmatique de perte de paquets. Un protocole de voix ou vidéo sur IP, style RTSP,doitc être capable de perdre ou de mélanger des paquets. Ca supporte ça un protocole de chiffrement en flux (stream cipher) ?
On a l'exemple du GSM, et son A5, qui est un algo de chiffrement de flux. Je ne pense pas que les paquets puissent arriver dans le désordre (la station de base doit s'arranger pour respecter l'ordre), mais il peut y avoir de la perte, et le canal peut être fortement bruité.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- J'arrête pas d'essayer de m'abonner au mailing list sur la Nippon animation, mais le machin auromatique MAJORDOMO me renvoit toujours la même foutu page d'instruction de code. Comment ca marche ? -+- W in Guide du Neuneu d'Usenet : Mauvais abonné, changer d'abonné -+-
Bonjour,
On Fri, 8 Apr 2005, Fabrice Bacchella wrote:
On 7 Apr 2005 17:26:18 -0700, thehermes@altern.org (yu) wrote:
N'oublions pas la problèmatique de perte de paquets. Un protocole de
voix ou vidéo sur IP, style RTSP,doitc être capable de perdre ou de
mélanger des paquets. Ca supporte ça un protocole de chiffrement en
flux (stream cipher) ?
On a l'exemple du GSM, et son A5, qui est un algo de chiffrement de flux.
Je ne pense pas que les paquets puissent arriver dans le désordre (la
station de base doit s'arranger pour respecter l'ordre), mais il peut y
avoir de la perte, et le canal peut être fortement bruité.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
J'arrête pas d'essayer de m'abonner au mailing list sur la Nippon
animation, mais le machin auromatique MAJORDOMO me renvoit toujours la
même foutu page d'instruction de code. Comment ca marche ?
-+- W in Guide du Neuneu d'Usenet : Mauvais abonné, changer d'abonné -+-
N'oublions pas la problèmatique de perte de paquets. Un protocole de voix ou vidéo sur IP, style RTSP,doitc être capable de perdre ou de mélanger des paquets. Ca supporte ça un protocole de chiffrement en flux (stream cipher) ?
On a l'exemple du GSM, et son A5, qui est un algo de chiffrement de flux. Je ne pense pas que les paquets puissent arriver dans le désordre (la station de base doit s'arranger pour respecter l'ordre), mais il peut y avoir de la perte, et le canal peut être fortement bruité.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- J'arrête pas d'essayer de m'abonner au mailing list sur la Nippon animation, mais le machin auromatique MAJORDOMO me renvoit toujours la même foutu page d'instruction de code. Comment ca marche ? -+- W in Guide du Neuneu d'Usenet : Mauvais abonné, changer d'abonné -+-
chaton
yu wrote:
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.
Je ne connais pas le logiciel donc je ne ferais pas de suppositions sur son fonctionnement mais:
"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."
La je ne vois absolument pas ou se trouve le probleme, le chiffrement pas bloc ne necessite pas forcement de connaitre l'integrite du message pour chiffrer ou dechiffrer puisque par exemple les modes comme ECB ou CBC sont senses pouvoir etre parallelisables. Dans le mode ECB on ne se soucie que du bloc courant, et dans le mode CBC que du bloc courant et de celui qui le precede. Pourquoi n' auraient ils pu pas proceder a un chiffrement AES avec padding des donnees ?
"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."
Pourquoi ? Un algorithme est fiable ou non independamment du mode dans lequel il est utilise, donc en utilisant AES qui est, pour l'instant du moins, fiable en mode CFB ils sont assures que le chiffrement est efficace. De plus le calcul superflu est relativement peu important puisque si l'on compare avec un AES en mode CBC par exemple, la difference se resume, a peu de choses pres, a l'utilisation d'un bloc supplementaire pour le buffer de retroaction et a une serie de decalages, ce qui est loin d'etre le plus couteux dans l'implementation de l'algorithme.
" 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"
Je trouve que c'est un peu leger de faire ce genre d'assertions, il existe de bons algorithmes de chiffrement par flot et de mauvais algorithmes de chiffrement par bloc (j'en ai d'ailleurs fait quelques uns de tres mauvais moi meme ;). En pratique, le fait de bosser sur un bloc permets de bien repartir la diffusion et la confusion, ce qui n'est pas forcement faisable sur du chiffrement bit a bit puisque par definition le chiffrement par flot est sense pouvoir chiffrer des donnees "pas encore disponibles", mais avec des methodes assimilees aux reseaux de Feistel, tu peux litteralement "pourrir" un buffer de retroaction qui applique par ou exclusif au flot de bits produira un resultat on ne peux plus dur a analyser. Je crois pas qu'on puisse faire des generalites dans le domaine, tous les avis dependent d'algos specifiques.
" On dit souvent que les chiffre par flot utilisent moins de ressources que leur homologues block cipher."
je ne sais pas de quel type de resources tu parles, en memoire en tout cas tu as une utilisation generalement moindre pour les stream ciphers.
yu wrote:
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.
Je ne connais pas le logiciel donc je ne ferais pas de suppositions sur
son
fonctionnement mais:
"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."
La je ne vois absolument pas ou se trouve le probleme, le chiffrement
pas bloc
ne necessite pas forcement de connaitre l'integrite du message pour
chiffrer ou
dechiffrer puisque par exemple les modes comme ECB ou CBC sont senses
pouvoir
etre parallelisables. Dans le mode ECB on ne se soucie que du bloc
courant, et
dans le mode CBC que du bloc courant et de celui qui le precede.
Pourquoi n'
auraient ils pu pas proceder a un chiffrement AES avec padding des
donnees ?
"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."
Pourquoi ? Un algorithme est fiable ou non independamment du mode dans
lequel
il est utilise, donc en utilisant AES qui est, pour l'instant du moins,
fiable
en mode CFB ils sont assures que le chiffrement est efficace. De plus
le calcul
superflu est relativement peu important puisque si l'on compare avec un
AES en
mode CBC par exemple, la difference se resume, a peu de choses pres, a
l'utilisation d'un bloc supplementaire pour le buffer de retroaction et
a une
serie de decalages, ce qui est loin d'etre le plus couteux dans
l'implementation
de l'algorithme.
" 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"
Je trouve que c'est un peu leger de faire ce genre d'assertions, il
existe
de bons algorithmes de chiffrement par flot et de mauvais algorithmes
de
chiffrement par bloc (j'en ai d'ailleurs fait quelques uns de tres
mauvais
moi meme ;). En pratique, le fait de bosser sur un bloc permets de bien
repartir la diffusion et la confusion, ce qui n'est pas forcement
faisable
sur du chiffrement bit a bit puisque par definition le chiffrement par
flot
est sense pouvoir chiffrer des donnees "pas encore disponibles", mais
avec
des methodes assimilees aux reseaux de Feistel, tu peux litteralement
"pourrir" un buffer de retroaction qui applique par ou exclusif au flot
de
bits produira un resultat on ne peux plus dur a analyser.
Je crois pas qu'on puisse faire des generalites dans le domaine, tous
les
avis dependent d'algos specifiques.
" On dit souvent que les chiffre par flot
utilisent moins de ressources que leur homologues block cipher."
je ne sais pas de quel type de resources tu parles, en memoire en tout
cas tu
as une utilisation generalement moindre pour les stream ciphers.
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.
Je ne connais pas le logiciel donc je ne ferais pas de suppositions sur son fonctionnement mais:
"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."
La je ne vois absolument pas ou se trouve le probleme, le chiffrement pas bloc ne necessite pas forcement de connaitre l'integrite du message pour chiffrer ou dechiffrer puisque par exemple les modes comme ECB ou CBC sont senses pouvoir etre parallelisables. Dans le mode ECB on ne se soucie que du bloc courant, et dans le mode CBC que du bloc courant et de celui qui le precede. Pourquoi n' auraient ils pu pas proceder a un chiffrement AES avec padding des donnees ?
"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."
Pourquoi ? Un algorithme est fiable ou non independamment du mode dans lequel il est utilise, donc en utilisant AES qui est, pour l'instant du moins, fiable en mode CFB ils sont assures que le chiffrement est efficace. De plus le calcul superflu est relativement peu important puisque si l'on compare avec un AES en mode CBC par exemple, la difference se resume, a peu de choses pres, a l'utilisation d'un bloc supplementaire pour le buffer de retroaction et a une serie de decalages, ce qui est loin d'etre le plus couteux dans l'implementation de l'algorithme.
" 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"
Je trouve que c'est un peu leger de faire ce genre d'assertions, il existe de bons algorithmes de chiffrement par flot et de mauvais algorithmes de chiffrement par bloc (j'en ai d'ailleurs fait quelques uns de tres mauvais moi meme ;). En pratique, le fait de bosser sur un bloc permets de bien repartir la diffusion et la confusion, ce qui n'est pas forcement faisable sur du chiffrement bit a bit puisque par definition le chiffrement par flot est sense pouvoir chiffrer des donnees "pas encore disponibles", mais avec des methodes assimilees aux reseaux de Feistel, tu peux litteralement "pourrir" un buffer de retroaction qui applique par ou exclusif au flot de bits produira un resultat on ne peux plus dur a analyser. Je crois pas qu'on puisse faire des generalites dans le domaine, tous les avis dependent d'algos specifiques.
" On dit souvent que les chiffre par flot utilisent moins de ressources que leur homologues block cipher."
je ne sais pas de quel type de resources tu parles, en memoire en tout cas tu as une utilisation generalement moindre pour les stream ciphers.
thehermes
Merci pour toutes ces reponses pertinentes. Je suis content que vous ayez pu me repondre et m'eclairer un peu sur la question, c'est tres sympa.
Merci pour toutes ces reponses pertinentes. Je suis content que vous
ayez pu me repondre et m'eclairer un peu sur la question, c'est tres
sympa.
