Dans l'affaire "Clearstream" M. De Villepin c'est fait saisir un DVD
Crypt=E9, plusieur services on dit ne pas r=E9ussir =E0 casser le cryptage !=
( dont les pandores qui [sic] se dit =EAtre le service le plus renom=E9 du
territoire !)
Quelqu'un conn=E9 l'algo ?
Platforme MS ....
( peur-=EAtre un contenere !? )
Le (on) samedi 15 mars 2008 08:28, ptilou a écrit (wrote) :
Un Cours de mathématique, sur les probabilités seraient à même d'éclairer certains
Je n'ai rien à rajouter :-)
Manuel.
PS : j'aime bien la majuscule à « Cours » pour bien en souligner l'importance, ainsi que la subtile allusion bourbakiste qui suit...
Al
Bonjour,
On 12 mar, 20:19, mpg wrote:
Le (on) mercredi 12 mars 2008 09:49, ptilou a écrit (wrote) :
Euh c'est 7 ou 8 bits par caractère Non non. Ne confond pas le codage ASCII à 7 ou 8 bits et le nombre de
bits nécessaires pour stocker une information : ici 52 + 10 = 60 combinaisons. Log2(60) = ln(60)/ln(2) = approx 5.91 donc moins de 6 bits par caractère...
Un Cours de mathématique, sur les probabilités seraient à même d'éclairer certains
en fait, le cours les plus adapté c'est "théorie de l'information", qui fait grand usage d'une base de probabilité.
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon c'est que ca chiffre mal. pourquoi il y a avantage a compresser avant de chiffre pour protéger un algo faible.
... combien tentent encore de compresser du MPEG, ou compresser un conteneur chiffré... la théorie de l'information c'est un peu la thermodynamique de l'informatique.
Bonjour,
On 12 mar, 20:19, mpg <m...@elzevir.fr> wrote:
Le (on) mercredi 12 mars 2008 09:49, ptilou a écrit (wrote) :
Euh c'est 7 ou 8 bits par caractère
Non non. Ne confond pas le codage ASCII à 7 ou 8 bits et le nombre de
bits nécessaires pour stocker une information :
ici 52 + 10 = 60 combinaisons.
Log2(60) = ln(60)/ln(2) = approx 5.91 donc moins de 6 bits par
caractère...
Un Cours de mathématique, sur les probabilités seraient à même
d'éclairer certains
en fait, le cours les plus adapté c'est "théorie de l'information", qui
fait grand usage d'une base de probabilité.
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de
passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon
c'est que ca chiffre mal.
pourquoi il y a avantage a compresser avant de chiffre pour protéger un
algo faible.
... combien tentent encore de compresser du MPEG, ou compresser un
conteneur chiffré...
la théorie de l'information c'est un peu la thermodynamique de
l'informatique.
Le (on) mercredi 12 mars 2008 09:49, ptilou a écrit (wrote) :
Euh c'est 7 ou 8 bits par caractère Non non. Ne confond pas le codage ASCII à 7 ou 8 bits et le nombre de
bits nécessaires pour stocker une information : ici 52 + 10 = 60 combinaisons. Log2(60) = ln(60)/ln(2) = approx 5.91 donc moins de 6 bits par caractère...
Un Cours de mathématique, sur les probabilités seraient à même d'éclairer certains
en fait, le cours les plus adapté c'est "théorie de l'information", qui fait grand usage d'une base de probabilité.
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon c'est que ca chiffre mal. pourquoi il y a avantage a compresser avant de chiffre pour protéger un algo faible.
... combien tentent encore de compresser du MPEG, ou compresser un conteneur chiffré... la théorie de l'information c'est un peu la thermodynamique de l'informatique.
mpg
Le (on) samedi 15 mars 2008 12:43, Al a écrit (wrote) :
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon c'est que ca chiffre mal. pourquoi il y a avantage a compresser avant de chiffre pour protéger un algo faible.
D'ailleurs, c'est juste pour les algos faibles ou ça se fait en général ?
Par exemple, pour un mail chiffré avec GPG (il me semble que le texte, c'est typiquement un truc qui se compresse très bien), le texte va-t-il être compressé avant, ou on estime que l'algo (typiquement AES) utilisé est assez robuste (ou que le message est en moyenne trop court pour exploiter les redondances), ou... ?
Manuel.
Le (on) samedi 15 mars 2008 12:43, Al a écrit (wrote) :
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de
passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon
c'est que ca chiffre mal.
pourquoi il y a avantage a compresser avant de chiffre pour protéger un
algo faible.
D'ailleurs, c'est juste pour les algos faibles ou ça se fait en général ?
Par exemple, pour un mail chiffré avec GPG (il me semble que le texte,
c'est typiquement un truc qui se compresse très bien), le texte va-t-il
être compressé avant, ou on estime que l'algo (typiquement AES) utilisé est
assez robuste (ou que le message est en moyenne trop court pour exploiter
les redondances), ou... ?
Le (on) samedi 15 mars 2008 12:43, Al a écrit (wrote) :
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon c'est que ca chiffre mal. pourquoi il y a avantage a compresser avant de chiffre pour protéger un algo faible.
D'ailleurs, c'est juste pour les algos faibles ou ça se fait en général ?
Par exemple, pour un mail chiffré avec GPG (il me semble que le texte, c'est typiquement un truc qui se compresse très bien), le texte va-t-il être compressé avant, ou on estime que l'algo (typiquement AES) utilisé est assez robuste (ou que le message est en moyenne trop court pour exploiter les redondances), ou... ?
Manuel.
Sylvain
mpg wrote on 15/03/2008 13:28:
Le (on) samedi 15 mars 2008 12:43, Al a écrit (wrote) :
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon c'est que ca chiffre mal. pourquoi il y a avantage a compresser avant de chiffre pour protéger un algo faible.
D'ailleurs, c'est juste pour les algos faibles ou ça se fait en général ?
Par exemple, pour un mail chiffré avec GPG (il me semble que le texte, c'est typiquement un truc qui se compresse très bien), le texte va-t-il être compressé avant, ou on estime que l'algo (typiquement AES) utilisé est assez robuste (ou que le message est en moyenne trop court pour exploiter les redondances), ou... ?
pour les algos faibles. où "faible" signifie ici ques des pattern répétés dans le clair génèrerait des pattern également répétés dans le chiffré.
pour éviter cela (même si une meilleure solution serait de changer d'algo de chiffrement) est de compresser le clair afin d'obtenir un truc sans répétition [1] qui donnera un chiffré sans répétition.
[1] si le compressé contenait des répétitions ce serait évidemment que la compression est non performante.
si l'algo n'est pas "faible" (au sens ci-dessus) un chiffrement de texte peut se faire sur le texte brut; le compresser avant chiffrement peut avoir un sens (être pertinent) mais seulement pour réduire le volume à échanger, stocker, etc. cette compression est indépendante du chiffrement et sera à la libre initiative de l'utilisateur.
Sylvain.
mpg wrote on 15/03/2008 13:28:
Le (on) samedi 15 mars 2008 12:43, Al a écrit (wrote) :
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de
passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon
c'est que ca chiffre mal.
pourquoi il y a avantage a compresser avant de chiffre pour protéger un
algo faible.
D'ailleurs, c'est juste pour les algos faibles ou ça se fait en général ?
Par exemple, pour un mail chiffré avec GPG (il me semble que le texte,
c'est typiquement un truc qui se compresse très bien), le texte va-t-il
être compressé avant, ou on estime que l'algo (typiquement AES) utilisé est
assez robuste (ou que le message est en moyenne trop court pour exploiter
les redondances), ou... ?
pour les algos faibles. où "faible" signifie ici ques des pattern
répétés dans le clair génèrerait des pattern également répétés
dans le chiffré.
pour éviter cela (même si une meilleure solution serait de changer
d'algo de chiffrement) est de compresser le clair afin d'obtenir
un truc sans répétition [1] qui donnera un chiffré sans répétition.
[1] si le compressé contenait des répétitions ce serait évidemment
que la compression est non performante.
si l'algo n'est pas "faible" (au sens ci-dessus) un chiffrement de
texte peut se faire sur le texte brut; le compresser avant chiffrement
peut avoir un sens (être pertinent) mais seulement pour réduire le
volume à échanger, stocker, etc. cette compression est indépendante
du chiffrement et sera à la libre initiative de l'utilisateur.
Le (on) samedi 15 mars 2008 12:43, Al a écrit (wrote) :
ca permet d'expliquer ce qu'est une compression, l'entropie d'un mot de passe, pourquoi on ne doit pas pouvoir compresser un chiffré, sinon c'est que ca chiffre mal. pourquoi il y a avantage a compresser avant de chiffre pour protéger un algo faible.
D'ailleurs, c'est juste pour les algos faibles ou ça se fait en général ?
Par exemple, pour un mail chiffré avec GPG (il me semble que le texte, c'est typiquement un truc qui se compresse très bien), le texte va-t-il être compressé avant, ou on estime que l'algo (typiquement AES) utilisé est assez robuste (ou que le message est en moyenne trop court pour exploiter les redondances), ou... ?
pour les algos faibles. où "faible" signifie ici ques des pattern répétés dans le clair génèrerait des pattern également répétés dans le chiffré.
pour éviter cela (même si une meilleure solution serait de changer d'algo de chiffrement) est de compresser le clair afin d'obtenir un truc sans répétition [1] qui donnera un chiffré sans répétition.
[1] si le compressé contenait des répétitions ce serait évidemment que la compression est non performante.
si l'algo n'est pas "faible" (au sens ci-dessus) un chiffrement de texte peut se faire sur le texte brut; le compresser avant chiffrement peut avoir un sens (être pertinent) mais seulement pour réduire le volume à échanger, stocker, etc. cette compression est indépendante du chiffrement et sera à la libre initiative de l'utilisateur.
