On Mon, 19 Apr 2004 12:08:09 -0400, Guillermito wrote:
Ce qui me rappelle aussi que j'avais un projet à un moment donné (un des innombrables projets jamais réalisés) de créer un logiciel combinant stéganographie et cryptographie, qui aurait permis de cacher deux (ou plusieurs) fichiers. [...] En d'autres termes, pouvoir nier de manière convaincante la présence du fichier caché important, même si la stéganographie est détectable.
Le projet "Rubberhose" (http://www.rubberhose.org/) fait ça, entre autres pour permettre aux travailleurs humanitaires de donner quelques infos aux forces de police (par exemple dans le cas de tortures) sans compromettre l'intégralité de leurs données :
"Rubberhose transparently and deniably encrypts disk data, minimising the effectiveness of warrants, coersive interrogations and other compulsive mechanims, such as U.K RIP legislation."
Nicob
On Mon, 19 Apr 2004 12:08:09 -0400, Guillermito wrote:
Ce qui me rappelle aussi que j'avais un projet à un moment donné (un des
innombrables projets jamais réalisés) de créer un logiciel combinant
stéganographie et cryptographie, qui aurait permis de cacher deux (ou
plusieurs) fichiers. [...] En d'autres termes, pouvoir nier de manière
convaincante la présence du fichier caché important, même si la
stéganographie est détectable.
Le projet "Rubberhose" (http://www.rubberhose.org/) fait ça, entre autres
pour permettre aux travailleurs humanitaires de donner quelques infos aux
forces de police (par exemple dans le cas de tortures) sans compromettre
l'intégralité de leurs données :
"Rubberhose transparently and deniably encrypts disk data, minimising the
effectiveness of warrants, coersive interrogations and other compulsive
mechanims, such as U.K RIP legislation."
On Mon, 19 Apr 2004 12:08:09 -0400, Guillermito wrote:
Ce qui me rappelle aussi que j'avais un projet à un moment donné (un des innombrables projets jamais réalisés) de créer un logiciel combinant stéganographie et cryptographie, qui aurait permis de cacher deux (ou plusieurs) fichiers. [...] En d'autres termes, pouvoir nier de manière convaincante la présence du fichier caché important, même si la stéganographie est détectable.
Le projet "Rubberhose" (http://www.rubberhose.org/) fait ça, entre autres pour permettre aux travailleurs humanitaires de donner quelques infos aux forces de police (par exemple dans le cas de tortures) sans compromettre l'intégralité de leurs données :
"Rubberhose transparently and deniably encrypts disk data, minimising the effectiveness of warrants, coersive interrogations and other compulsive mechanims, such as U.K RIP legislation."
Nicob
Patrick \Zener\ Brunet
Bonjour.
Je suis parfaitement d'accord sur la différence qui doit être faite, dans un contexte professionnel, entre les notions de : - strictement (prouvé) incassable (donc indéchiffrable sans la clé), - difficilement cassable (difficulté estimable à partir de l'état *connu* de l'art et des technologies), - simplement obfusqué.
Le chiffrement de Vernam est prouvé incassable, mais pose le problème de la transmission de la clé, les systèmes professionnels actuels reposent sur le second principe, et le troisième est réservé aux amateurs ou aux pseudo-pros.
Je crois aussi que le choix entre les trois dépend de l'enjeu, et la qualité de l'attaquant aussi. Pour ce qui est du financement, j'avoue que je comprends assez les gens à qui on vend des solutions informatiques "miracles" depuis bientôt un demi-siècle, et qui cherchent surtout à limiter la gabegie.
Il est clair qu'il existe un gros problème actuellement avec les solutions à base de problèmes "difficiles" : cette difficulté s'effrite de jour en jour alors même que le besoin en robustesse ET longévité des protections croît dans de nombreux domaines. Ce qui justifie des recherches telles que la cryptologie quantique (qui vise le Vernam) mais qui est faillible par ailleurs.
Ma question se place donc dans le contexte professionnel et en haute sécurité, et pas dans le simple bricolage d'amateur : ===== Je cherche des références permettant de mesurer la difficulté - et idéalement de définir des critères d'impossibilité formelle - pour reconstituer une forme compressée (selon un algorithme adéquat) et ensuite *partiellement* (c'est tout l'intérêt) sabotée en des points critiques. ===== Si je pouvais voir cette théorie soutenue ou infirmée par des études précises, j'en serais très intéressé. Merci d'avance.
Cordialement,
PZB
----divers commentaires ci-après...
"Thomas Pornin" a écrit dans le message de news:c62j6m$1bv2$
According to Guillermito :
En théorie. Mais je suis persuadé aussi que dans la pratique, par exemple quand quelqu'un essaie de vraiment décrypter, par force brute ou autre, le message que j'ai fait passer à ma petite soeur, faire un double cryptage (ou compresser puis crypter) renforce la sécurité, notamment parce qu'il n'y a plus d'analyse de spectre possible.
En fait, le défenseur et l'attaquant sont dans deux mondes différents. L'attaquant a un problème concret sous la main ; dans le cas d'une recherche exhaustive (force brute sur la clé, dictionnaire sur un mot de passe...), l'attaquant a besoin d'un "test d'arrêt". Souvent, cela est fourni par le format de chiffrement lui-même (un checksum, par exemple). Parfois non. L'attaquant peut avoir beaucoup de mal à se débrouiller avec des chiffrements en cascade et diverses autres magouilles (l'inversion du 933ème octet, par exemple).
Mais ces magouilles ne sont pas décemment chiffrables et ne devraient donc pas intéresser le défenseur. En effet, celui qui chiffre les données veut deux choses : -- il veut que ses données restent confidentielles ; -- il veut en être persuadé _a priori_.
J'en connais au moins un qui a envie d'une preuve formelle.
Stricto sensu, il ne veut pas un système inattaquable, il veut un système inattaqué, et, si possible, que le coût de l'attaque soit chiffrable précisément. Dans une logique industrielle, un système à sécurité mesurable, c'est un système pour lequel on peut faire de la prévision de risques, et donc pour lequel on peut prendre une assurance.
Il y a des choses que l'argent ne peut pas réparer. Je crois que l'enjeu peut conduire à d'autres raisonnements.
Les assureurs ont horreur des cryptanalystes qui disent "c'est incassable" parce que cette notion d'incassabilité est mathématique au lieu d'être comptable. C'est en dehors du monde sur lequel ils savent faire leur travail.
Comment réagissent-ils si on peut leur prouver par A+B la robustesse du système (i.e.: que l'attaque est formellement impossible sans remplir une liste précise de conditions, de préférence C+D_inaccessibles) ?
Cette notion s'étend aux magouilles dont je parle plus haut : oui, elles compliquent la vie de l'attaquant, mais non, on ne sait pas dire à quel point. C'est comme le fait de conserver l'algorithme secret : ça n'arrange pas l'attaquant, qui va devoir se taper le travail de reverse-engineering. Mais il est très difficile de savoir si l'attaquant va réussir ledit reverse-engineering, et à quel coût (en temps et en argent). Donc une politique de sécurité bien sentie ne doit pas se fonder sur ce genre de choses.
Le secret de l'algorithme va contre les principes de Kerschoff.
Dixit E.A. Poe : "il n'est rien qu'une intelligence humaine puisse faire et qu'aucune autre ne puisse défaire". C'est donc une question d'enjeu, et de délai en comptant sur la griserie d'un tel défi, et sur l'évolution des technologies. Donc je pense que sans preuve formelle, il n'est pas question de sécurité absolue, seulement (très) relative.
Bizarrement, l'utilisateur moyen, même bien informé, à plus confiance en ses gadgets personnels (le 933ème octet inversé, remplacer les noms par des anagrammes, ...) qu'en l'algorithme principal, pourtant étudié et analysé par des hordes de cryptographes dont c'est le métier. On pourrait dire que ces amusements sont bels et bons, s'ils permettent à l'utilisateur de dormir sur ses deux oreilles, mais ils fournissent un sentiment de fausse sécurité qui pousse l'usager à négliger, à terme, les précautions qui sont le vrai fondement de la sécurité de ses données. C'est donc, dans l'ensemble, nuisible.
Je dirais même qu'affirmer au client qu'une bidouille est incassable sans être capable de le prouver relève de l'escroquerie !
<...>
Dans l'ensemble, les cryptographes préfèrent ne pas se reposer sur l'aspect aléatoire d'un système de compression, quand on en est à faire de la sécurité, parce que ce n'est pas mesurable décemment. Ils préfèrent avoir des systèmes de chiffrement, qui chiffrent, et des systèmes de compression, qui compressent.
J'approuve la modularité, mais donc comme je le dis plus haut, profiter d'un format caractéristique (et formalisé, il n'est pas question d'un simple "aspect aléatoire") de la forme compressée pour la brouiller de manière intelligente et prouvée irréversible me paraît une solution à creuser pour les gros volumes de données.
Cordialement, PZB
--Thomas Pornin
Bonjour.
Je suis parfaitement d'accord sur la différence qui doit être faite, dans un
contexte professionnel, entre les notions de :
- strictement (prouvé) incassable (donc indéchiffrable sans la clé),
- difficilement cassable (difficulté estimable à partir de l'état *connu* de
l'art et des technologies),
- simplement obfusqué.
Le chiffrement de Vernam est prouvé incassable, mais pose le problème de la
transmission de la clé, les systèmes professionnels actuels reposent sur le
second principe, et le troisième est réservé aux amateurs ou aux
pseudo-pros.
Je crois aussi que le choix entre les trois dépend de l'enjeu, et la qualité
de l'attaquant aussi. Pour ce qui est du financement, j'avoue que je
comprends assez les gens à qui on vend des solutions informatiques
"miracles" depuis bientôt un demi-siècle, et qui cherchent surtout à limiter
la gabegie.
Il est clair qu'il existe un gros problème actuellement avec les solutions à
base de problèmes "difficiles" : cette difficulté s'effrite de jour en jour
alors même que le besoin en robustesse ET longévité des protections croît
dans de nombreux domaines.
Ce qui justifie des recherches telles que la cryptologie quantique (qui vise
le Vernam) mais qui est faillible par ailleurs.
Ma question se place donc dans le contexte professionnel et en haute
sécurité, et pas dans le simple bricolage d'amateur :
===== Je cherche des références permettant de mesurer la difficulté - et
idéalement de définir des critères d'impossibilité formelle - pour
reconstituer une forme compressée (selon un algorithme adéquat) et ensuite
*partiellement* (c'est tout l'intérêt) sabotée en des points critiques.
=====
Si je pouvais voir cette théorie soutenue ou infirmée par des études
précises, j'en serais très intéressé.
Merci d'avance.
Cordialement,
PZB
----divers commentaires ci-après...
"Thomas Pornin" <pornin@nerim.net> a écrit dans le message de
news:c62j6m$1bv2$1@biggoron.nerim.net...
According to Guillermito <guillermito@pipo.com>:
En théorie. Mais je suis persuadé aussi que dans la pratique, par
exemple quand quelqu'un essaie de vraiment décrypter, par force brute
ou autre, le message que j'ai fait passer à ma petite soeur, faire un
double cryptage (ou compresser puis crypter) renforce la sécurité,
notamment parce qu'il n'y a plus d'analyse de spectre possible.
En fait, le défenseur et l'attaquant sont dans deux mondes différents.
L'attaquant a un problème concret sous la main ; dans le cas d'une
recherche exhaustive (force brute sur la clé, dictionnaire sur un
mot de passe...), l'attaquant a besoin d'un "test d'arrêt". Souvent,
cela est fourni par le format de chiffrement lui-même (un checksum,
par exemple). Parfois non. L'attaquant peut avoir beaucoup de mal à
se débrouiller avec des chiffrements en cascade et diverses autres
magouilles (l'inversion du 933ème octet, par exemple).
Mais ces magouilles ne sont pas décemment chiffrables et ne devraient
donc pas intéresser le défenseur. En effet, celui qui chiffre les
données veut deux choses :
-- il veut que ses données restent confidentielles ;
-- il veut en être persuadé _a priori_.
J'en connais au moins un qui a envie d'une preuve formelle.
Stricto sensu, il ne veut pas un système inattaquable, il veut un
système inattaqué, et, si possible, que le coût de l'attaque soit
chiffrable précisément. Dans une logique industrielle, un système
à sécurité mesurable, c'est un système pour lequel on peut faire
de la prévision de risques, et donc pour lequel on peut prendre
une assurance.
Il y a des choses que l'argent ne peut pas réparer. Je crois que l'enjeu
peut conduire à d'autres raisonnements.
Les assureurs ont horreur des cryptanalystes qui
disent "c'est incassable" parce que cette notion d'incassabilité est
mathématique au lieu d'être comptable. C'est en dehors du monde sur
lequel ils savent faire leur travail.
Comment réagissent-ils si on peut leur prouver par A+B la robustesse du
système (i.e.: que l'attaque est formellement impossible sans remplir une
liste précise de conditions, de préférence C+D_inaccessibles) ?
Cette notion s'étend aux magouilles dont je parle plus haut : oui,
elles compliquent la vie de l'attaquant, mais non, on ne sait pas dire
à quel point. C'est comme le fait de conserver l'algorithme secret :
ça n'arrange pas l'attaquant, qui va devoir se taper le travail de
reverse-engineering. Mais il est très difficile de savoir si l'attaquant
va réussir ledit reverse-engineering, et à quel coût (en temps et en
argent). Donc une politique de sécurité bien sentie ne doit pas se
fonder sur ce genre de choses.
Le secret de l'algorithme va contre les principes de Kerschoff.
Dixit E.A. Poe : "il n'est rien qu'une intelligence humaine puisse faire et
qu'aucune autre ne puisse défaire".
C'est donc une question d'enjeu, et de délai en comptant sur la griserie
d'un tel défi, et sur l'évolution des technologies.
Donc je pense que sans preuve formelle, il n'est pas question de sécurité
absolue, seulement (très) relative.
Bizarrement, l'utilisateur moyen, même bien informé, à plus confiance
en ses gadgets personnels (le 933ème octet inversé, remplacer les noms
par des anagrammes, ...) qu'en l'algorithme principal, pourtant étudié
et analysé par des hordes de cryptographes dont c'est le métier. On
pourrait dire que ces amusements sont bels et bons, s'ils permettent
à l'utilisateur de dormir sur ses deux oreilles, mais ils fournissent
un sentiment de fausse sécurité qui pousse l'usager à négliger, à
terme, les précautions qui sont le vrai fondement de la sécurité de ses
données. C'est donc, dans l'ensemble, nuisible.
Je dirais même qu'affirmer au client qu'une bidouille est incassable sans
être capable de le prouver relève de l'escroquerie !
<...>
Dans l'ensemble, les cryptographes préfèrent ne pas se reposer sur
l'aspect aléatoire d'un système de compression, quand on en est à
faire de la sécurité, parce que ce n'est pas mesurable décemment. Ils
préfèrent avoir des systèmes de chiffrement, qui chiffrent, et des
systèmes de compression, qui compressent.
J'approuve la modularité, mais donc comme je le dis plus haut, profiter d'un
format caractéristique (et formalisé, il n'est pas question d'un simple
"aspect aléatoire") de la forme compressée pour la brouiller de manière
intelligente et prouvée irréversible me paraît une solution à creuser pour
les gros volumes de données.
Je suis parfaitement d'accord sur la différence qui doit être faite, dans un contexte professionnel, entre les notions de : - strictement (prouvé) incassable (donc indéchiffrable sans la clé), - difficilement cassable (difficulté estimable à partir de l'état *connu* de l'art et des technologies), - simplement obfusqué.
Le chiffrement de Vernam est prouvé incassable, mais pose le problème de la transmission de la clé, les systèmes professionnels actuels reposent sur le second principe, et le troisième est réservé aux amateurs ou aux pseudo-pros.
Je crois aussi que le choix entre les trois dépend de l'enjeu, et la qualité de l'attaquant aussi. Pour ce qui est du financement, j'avoue que je comprends assez les gens à qui on vend des solutions informatiques "miracles" depuis bientôt un demi-siècle, et qui cherchent surtout à limiter la gabegie.
Il est clair qu'il existe un gros problème actuellement avec les solutions à base de problèmes "difficiles" : cette difficulté s'effrite de jour en jour alors même que le besoin en robustesse ET longévité des protections croît dans de nombreux domaines. Ce qui justifie des recherches telles que la cryptologie quantique (qui vise le Vernam) mais qui est faillible par ailleurs.
Ma question se place donc dans le contexte professionnel et en haute sécurité, et pas dans le simple bricolage d'amateur : ===== Je cherche des références permettant de mesurer la difficulté - et idéalement de définir des critères d'impossibilité formelle - pour reconstituer une forme compressée (selon un algorithme adéquat) et ensuite *partiellement* (c'est tout l'intérêt) sabotée en des points critiques. ===== Si je pouvais voir cette théorie soutenue ou infirmée par des études précises, j'en serais très intéressé. Merci d'avance.
Cordialement,
PZB
----divers commentaires ci-après...
"Thomas Pornin" a écrit dans le message de news:c62j6m$1bv2$
According to Guillermito :
En théorie. Mais je suis persuadé aussi que dans la pratique, par exemple quand quelqu'un essaie de vraiment décrypter, par force brute ou autre, le message que j'ai fait passer à ma petite soeur, faire un double cryptage (ou compresser puis crypter) renforce la sécurité, notamment parce qu'il n'y a plus d'analyse de spectre possible.
En fait, le défenseur et l'attaquant sont dans deux mondes différents. L'attaquant a un problème concret sous la main ; dans le cas d'une recherche exhaustive (force brute sur la clé, dictionnaire sur un mot de passe...), l'attaquant a besoin d'un "test d'arrêt". Souvent, cela est fourni par le format de chiffrement lui-même (un checksum, par exemple). Parfois non. L'attaquant peut avoir beaucoup de mal à se débrouiller avec des chiffrements en cascade et diverses autres magouilles (l'inversion du 933ème octet, par exemple).
Mais ces magouilles ne sont pas décemment chiffrables et ne devraient donc pas intéresser le défenseur. En effet, celui qui chiffre les données veut deux choses : -- il veut que ses données restent confidentielles ; -- il veut en être persuadé _a priori_.
J'en connais au moins un qui a envie d'une preuve formelle.
Stricto sensu, il ne veut pas un système inattaquable, il veut un système inattaqué, et, si possible, que le coût de l'attaque soit chiffrable précisément. Dans une logique industrielle, un système à sécurité mesurable, c'est un système pour lequel on peut faire de la prévision de risques, et donc pour lequel on peut prendre une assurance.
Il y a des choses que l'argent ne peut pas réparer. Je crois que l'enjeu peut conduire à d'autres raisonnements.
Les assureurs ont horreur des cryptanalystes qui disent "c'est incassable" parce que cette notion d'incassabilité est mathématique au lieu d'être comptable. C'est en dehors du monde sur lequel ils savent faire leur travail.
Comment réagissent-ils si on peut leur prouver par A+B la robustesse du système (i.e.: que l'attaque est formellement impossible sans remplir une liste précise de conditions, de préférence C+D_inaccessibles) ?
Cette notion s'étend aux magouilles dont je parle plus haut : oui, elles compliquent la vie de l'attaquant, mais non, on ne sait pas dire à quel point. C'est comme le fait de conserver l'algorithme secret : ça n'arrange pas l'attaquant, qui va devoir se taper le travail de reverse-engineering. Mais il est très difficile de savoir si l'attaquant va réussir ledit reverse-engineering, et à quel coût (en temps et en argent). Donc une politique de sécurité bien sentie ne doit pas se fonder sur ce genre de choses.
Le secret de l'algorithme va contre les principes de Kerschoff.
Dixit E.A. Poe : "il n'est rien qu'une intelligence humaine puisse faire et qu'aucune autre ne puisse défaire". C'est donc une question d'enjeu, et de délai en comptant sur la griserie d'un tel défi, et sur l'évolution des technologies. Donc je pense que sans preuve formelle, il n'est pas question de sécurité absolue, seulement (très) relative.
Bizarrement, l'utilisateur moyen, même bien informé, à plus confiance en ses gadgets personnels (le 933ème octet inversé, remplacer les noms par des anagrammes, ...) qu'en l'algorithme principal, pourtant étudié et analysé par des hordes de cryptographes dont c'est le métier. On pourrait dire que ces amusements sont bels et bons, s'ils permettent à l'utilisateur de dormir sur ses deux oreilles, mais ils fournissent un sentiment de fausse sécurité qui pousse l'usager à négliger, à terme, les précautions qui sont le vrai fondement de la sécurité de ses données. C'est donc, dans l'ensemble, nuisible.
Je dirais même qu'affirmer au client qu'une bidouille est incassable sans être capable de le prouver relève de l'escroquerie !
<...>
Dans l'ensemble, les cryptographes préfèrent ne pas se reposer sur l'aspect aléatoire d'un système de compression, quand on en est à faire de la sécurité, parce que ce n'est pas mesurable décemment. Ils préfèrent avoir des systèmes de chiffrement, qui chiffrent, et des systèmes de compression, qui compressent.
J'approuve la modularité, mais donc comme je le dis plus haut, profiter d'un format caractéristique (et formalisé, il n'est pas question d'un simple "aspect aléatoire") de la forme compressée pour la brouiller de manière intelligente et prouvée irréversible me paraît une solution à creuser pour les gros volumes de données.
