je m'interroge sur les possibilites d'attaque sur une partition
chiffree sous linux a l'aide de cryptsetup et dm-crypt.
Il existe une grande variete de chiffrements:
iblkcipher.ko cast5.ko des.ko michael_mic.ko tea.ko
aes.ko cast6.ko ecb.ko pcbc.ko tgr192.ko
anubis.ko cbc.ko fcrypt.ko serpent.ko twofish.ko
arc4.ko crc32c.ko gf128mul.ko sha1.ko twofish_common.ko
blkcipher.ko cryptd.ko khazad.ko sha256.ko wp512.ko
blowfish.ko crypto_null.ko lrw.ko sha512.ko xcbc.ko
camellia.ko deflate.ko md4.ko tcrypt.ko
tous a utiliser avec mot de passe.
Le chiffrement s'effectue au niveau disque, c'est a dire qu'il
est necessaire de formater le device.
En bref, pour chiffrer il faut donc utiliser (par exemple):
echo "password" | cryptsetup -c aes create crypted_sda1 /dev/sda1
mke2fs /dev/mapper/crypted_sda1
Puis je peux monter ma partition, l'utiliser etc..
Ceci signifie donc trois composantes:
-le mot de passe
-le chiffrement utilisé
-le système de fichier utilisé
Maintenant, si je me place du cote de l'attaquant, qu'ai-je comme
angle d'attaque?
-le bruteforce de mot de passe?
Sauf que pour chaque mot de passe, il faut non seulement que je teste
tous les procedes de chiffrement (aes, puis blowfish, puis etc..) mais
aussi tous les filesystems (ext2, reiserfs, etc..)! D'un probleme a
une dimension (le mot de passe) on passe a trois dimensions (mot de
passe,chiffrement,filesystem).
Pour poser les questions autrement,
-est-ce possible de savoir que le mot de passe bruteforce est
le bon autrement qu'en montant la partition?
-est ce possible de connaitre le chiffrement utilise? comment?
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
Damien Wyart
* Kevin Denis in fr.misc.cryptologie:
je m'interroge sur les possibilites d'attaque sur une partition chiffree sous linux a l'aide de cryptsetup et dm-crypt.
Une première piste de lecture (pas neutre car c'est une personne proche de loo-AES si je me souviens bien) : http://mareichelt.de/pub/texts.cryptoloop.php
Pas trop le temps de répondre plus en détail maintenant, peut-être plus tard. C'est un thème assez bien documenté sur le net :
* Kevin Denis <kevin@nowher.invalid> in fr.misc.cryptologie:
je m'interroge sur les possibilites d'attaque sur une partition
chiffree sous linux a l'aide de cryptsetup et dm-crypt.
Une première piste de lecture (pas neutre car c'est une personne proche
de loo-AES si je me souviens bien) :
http://mareichelt.de/pub/texts.cryptoloop.php
Pas trop le temps de répondre plus en détail maintenant, peut-être plus
tard. C'est un thème assez bien documenté sur le net :
je m'interroge sur les possibilites d'attaque sur une partition chiffree sous linux a l'aide de cryptsetup et dm-crypt.
Une première piste de lecture (pas neutre car c'est une personne proche de loo-AES si je me souviens bien) : http://mareichelt.de/pub/texts.cryptoloop.php
Pas trop le temps de répondre plus en détail maintenant, peut-être plus tard. C'est un thème assez bien documenté sur le net :
Sauf que pour chaque mot de passe, il faut non seulement que je teste tous les procedes de chiffrement (aes, puis blowfish, puis etc..) mais aussi tous les filesystems (ext2, reiserfs, etc..)! D'un probleme a une dimension (le mot de passe) on passe a trois dimensions (mot de passe,chiffrement,filesystem). [...] Pour poser les questions autrement, -est-ce possible de savoir que le mot de passe bruteforce est le bon autrement qu'en montant la partition? -est ce possible de connaitre le chiffrement utilise? comment?
Dans une attaque un tant soit peu performante, ce sont normalement des problèmes mineurs.
Pour ce qui est du format de la partition, cette attaque performante va forcément pré-chargé en mémoire une partie de la partition chiffrée, puis pour chaque clé testé déchiffrer le bloc pré-chargé en mémoire, avant de chercher à indentifier si les données ressemble à un système de fichier connu.
Dans la phase préparatoire, l'attaquant déterminera en fonction des divers systèmes de fichiers quelle partie de la partition il faut précharger pour qu'une fois déchiffré, on puisse appliquer un algo qui reconnaitra des motifs spécifique à chacun des systèmes de fichier à identifier. Souvent, le premier bloc (8, 16 octets) suffira pour savoir que la clé n'est pas bonne. En fonction de chacun des systèmes, il est possible qu'on doive se compliquer la vie et que l'on soit forcé de déchiffrer plusieurs blocs pour prendre une décision. Mais sauf si le filesystem a vraiment été conçu spécifiquement pour rendre ce type d'attaque difficile, il est peu probable que cela alourdisse beaucoup les choses.
Dans tout ceci, les test réalisé après déchiffrement ont un coût quasi-nuls. Le seul cas où l'on sera ennuyé est donc si on doit déchiffrer des morceaux complètement différent de la partition suivant le système de fichier. Il me parait douteux aue ce soit le cas.
Pour la question de connaître l'algorithme de chiffrement, il est généralement indiqué en clair dans le format des donnnées chiffrées (c'est manifestement le cas pour cryptsetup puisque d'après ce que je vois on le précise seulement au formattage, pas au déchiffrement).
Et pourquoi ne pas chiffrer sans indiquer l'algorithme pour compliquer la vie à l'attaquant ? Parceque ça n'est pas efficace du tout.
A tout moment, il n'y qu'un nombre vraiment réduit d'algo qui soit au top en terme de confiance et de disponibilité. Du coup en testant seulement 5 ou 6 algo, multipliant donc ses tests par 5 ou 6, l'attaquant est garanti de couvrir plus de 90% des cas, alors qu'en ajoutant seulement 1 caractère au mot de passe, je multiplie par environ 60 le nombre de possibilité qu'il doit tester (sur un mdp aléatoire). Donc si je veux un truc plus sûr, rallonger un peu le mot de passe (ou m'assurer mieux qu'il est vraiment aléatoire) est beaucoup plus sûr et beaucoup plus efficace.
La réaction typique du néophyte auquel on décrit cela est très prévisible. Elle consiste à passer de l'inefficace (je choisis un algorithme populaire, très prévisible avec une liste de seulement 5 ou 6) au dangeureux (je sors des sentiers battus et je choisis un algorithme franchement exotique).
Dangeureux, car comme marqué plus haut si je veux être seulement aussi efficace que de rajouter 1 caractère à mon mot de passe, il va falloir que j'ai au moins 60 algorithmes entre lesquel choisir dans ma liste. Hors aujourd'hui je pense que si on demandait à un cryptographe de faire une liste exhaustive des algo qui lui semble dans l'état actuel des connaissances *vraiment* surs, je pense qu'il en citerait nettement moins de 60. Donc en s'efforceant de rajouter des algo à la liste pour augmenter la combinatoire, on rentre très fortement dans le risque d'en ajouter un peu utilisé, et aussi peu analysé, qui a une grosse faille qui sera dévoilé dans quelques temps. Toute cette complication, ce risque !, alors qu'il suffit d'ajouter un ou deux caractères au mot de passe pour avoir un meilleur gain de sécurité ? Ca n'a absolument aucun intérêt.
Kevin Denis wrote:
Sauf que pour chaque mot de passe, il faut non seulement que je teste
tous les procedes de chiffrement (aes, puis blowfish, puis etc..) mais
aussi tous les filesystems (ext2, reiserfs, etc..)! D'un probleme a
une dimension (le mot de passe) on passe a trois dimensions (mot de
passe,chiffrement,filesystem).
[...]
Pour poser les questions autrement,
-est-ce possible de savoir que le mot de passe bruteforce est
le bon autrement qu'en montant la partition?
-est ce possible de connaitre le chiffrement utilise? comment?
Dans une attaque un tant soit peu performante, ce sont normalement des
problèmes mineurs.
Pour ce qui est du format de la partition, cette attaque performante va
forcément pré-chargé en mémoire une partie de la partition chiffrée,
puis pour chaque clé testé déchiffrer le bloc pré-chargé en mémoire,
avant de chercher à indentifier si les données ressemble à un système de
fichier connu.
Dans la phase préparatoire, l'attaquant déterminera en fonction des
divers systèmes de fichiers quelle partie de la partition il faut
précharger pour qu'une fois déchiffré, on puisse appliquer un algo qui
reconnaitra des motifs spécifique à chacun des systèmes de fichier à
identifier. Souvent, le premier bloc (8, 16 octets) suffira pour savoir
que la clé n'est pas bonne.
En fonction de chacun des systèmes, il est possible qu'on doive se
compliquer la vie et que l'on soit forcé de déchiffrer plusieurs blocs
pour prendre une décision. Mais sauf si le filesystem a vraiment été
conçu spécifiquement pour rendre ce type d'attaque difficile, il est peu
probable que cela alourdisse beaucoup les choses.
Dans tout ceci, les test réalisé après déchiffrement ont un coût
quasi-nuls. Le seul cas où l'on sera ennuyé est donc si on doit
déchiffrer des morceaux complètement différent de la partition suivant
le système de fichier. Il me parait douteux aue ce soit le cas.
Pour la question de connaître l'algorithme de chiffrement, il est
généralement indiqué en clair dans le format des donnnées chiffrées
(c'est manifestement le cas pour cryptsetup puisque d'après ce que je
vois on le précise seulement au formattage, pas au déchiffrement).
Et pourquoi ne pas chiffrer sans indiquer l'algorithme pour compliquer
la vie à l'attaquant ? Parceque ça n'est pas efficace du tout.
A tout moment, il n'y qu'un nombre vraiment réduit d'algo qui soit au
top en terme de confiance et de disponibilité.
Du coup en testant seulement 5 ou 6 algo, multipliant donc ses tests par
5 ou 6, l'attaquant est garanti de couvrir plus de 90% des cas, alors
qu'en ajoutant seulement 1 caractère au mot de passe, je multiplie par
environ 60 le nombre de possibilité qu'il doit tester (sur un mdp
aléatoire).
Donc si je veux un truc plus sûr, rallonger un peu le mot de passe (ou
m'assurer mieux qu'il est vraiment aléatoire) est beaucoup plus sûr et
beaucoup plus efficace.
La réaction typique du néophyte auquel on décrit cela est très
prévisible. Elle consiste à passer de l'inefficace (je choisis un
algorithme populaire, très prévisible avec une liste de seulement 5 ou
6) au dangeureux (je sors des sentiers battus et je choisis un
algorithme franchement exotique).
Dangeureux, car comme marqué plus haut si je veux être seulement aussi
efficace que de rajouter 1 caractère à mon mot de passe, il va falloir
que j'ai au moins 60 algorithmes entre lesquel choisir dans ma liste.
Hors aujourd'hui je pense que si on demandait à un cryptographe de faire
une liste exhaustive des algo qui lui semble dans l'état actuel des
connaissances *vraiment* surs, je pense qu'il en citerait nettement
moins de 60.
Donc en s'efforceant de rajouter des algo à la liste pour augmenter la
combinatoire, on rentre très fortement dans le risque d'en ajouter un
peu utilisé, et aussi peu analysé, qui a une grosse faille qui sera
dévoilé dans quelques temps.
Toute cette complication, ce risque !, alors qu'il suffit d'ajouter un
ou deux caractères au mot de passe pour avoir un meilleur gain de
sécurité ? Ca n'a absolument aucun intérêt.
Sauf que pour chaque mot de passe, il faut non seulement que je teste tous les procedes de chiffrement (aes, puis blowfish, puis etc..) mais aussi tous les filesystems (ext2, reiserfs, etc..)! D'un probleme a une dimension (le mot de passe) on passe a trois dimensions (mot de passe,chiffrement,filesystem). [...] Pour poser les questions autrement, -est-ce possible de savoir que le mot de passe bruteforce est le bon autrement qu'en montant la partition? -est ce possible de connaitre le chiffrement utilise? comment?
Dans une attaque un tant soit peu performante, ce sont normalement des problèmes mineurs.
Pour ce qui est du format de la partition, cette attaque performante va forcément pré-chargé en mémoire une partie de la partition chiffrée, puis pour chaque clé testé déchiffrer le bloc pré-chargé en mémoire, avant de chercher à indentifier si les données ressemble à un système de fichier connu.
Dans la phase préparatoire, l'attaquant déterminera en fonction des divers systèmes de fichiers quelle partie de la partition il faut précharger pour qu'une fois déchiffré, on puisse appliquer un algo qui reconnaitra des motifs spécifique à chacun des systèmes de fichier à identifier. Souvent, le premier bloc (8, 16 octets) suffira pour savoir que la clé n'est pas bonne. En fonction de chacun des systèmes, il est possible qu'on doive se compliquer la vie et que l'on soit forcé de déchiffrer plusieurs blocs pour prendre une décision. Mais sauf si le filesystem a vraiment été conçu spécifiquement pour rendre ce type d'attaque difficile, il est peu probable que cela alourdisse beaucoup les choses.
Dans tout ceci, les test réalisé après déchiffrement ont un coût quasi-nuls. Le seul cas où l'on sera ennuyé est donc si on doit déchiffrer des morceaux complètement différent de la partition suivant le système de fichier. Il me parait douteux aue ce soit le cas.
Pour la question de connaître l'algorithme de chiffrement, il est généralement indiqué en clair dans le format des donnnées chiffrées (c'est manifestement le cas pour cryptsetup puisque d'après ce que je vois on le précise seulement au formattage, pas au déchiffrement).
Et pourquoi ne pas chiffrer sans indiquer l'algorithme pour compliquer la vie à l'attaquant ? Parceque ça n'est pas efficace du tout.
A tout moment, il n'y qu'un nombre vraiment réduit d'algo qui soit au top en terme de confiance et de disponibilité. Du coup en testant seulement 5 ou 6 algo, multipliant donc ses tests par 5 ou 6, l'attaquant est garanti de couvrir plus de 90% des cas, alors qu'en ajoutant seulement 1 caractère au mot de passe, je multiplie par environ 60 le nombre de possibilité qu'il doit tester (sur un mdp aléatoire). Donc si je veux un truc plus sûr, rallonger un peu le mot de passe (ou m'assurer mieux qu'il est vraiment aléatoire) est beaucoup plus sûr et beaucoup plus efficace.
La réaction typique du néophyte auquel on décrit cela est très prévisible. Elle consiste à passer de l'inefficace (je choisis un algorithme populaire, très prévisible avec une liste de seulement 5 ou 6) au dangeureux (je sors des sentiers battus et je choisis un algorithme franchement exotique).
Dangeureux, car comme marqué plus haut si je veux être seulement aussi efficace que de rajouter 1 caractère à mon mot de passe, il va falloir que j'ai au moins 60 algorithmes entre lesquel choisir dans ma liste. Hors aujourd'hui je pense que si on demandait à un cryptographe de faire une liste exhaustive des algo qui lui semble dans l'état actuel des connaissances *vraiment* surs, je pense qu'il en citerait nettement moins de 60. Donc en s'efforceant de rajouter des algo à la liste pour augmenter la combinatoire, on rentre très fortement dans le risque d'en ajouter un peu utilisé, et aussi peu analysé, qui a une grosse faille qui sera dévoilé dans quelques temps. Toute cette complication, ce risque !, alors qu'il suffit d'ajouter un ou deux caractères au mot de passe pour avoir un meilleur gain de sécurité ? Ca n'a absolument aucun intérêt.
offworld
Si c'est utilisé avec luks, voila le résultat retourné en cas de mauvais mot de passe :
Donc oui, le bruteforce est possible, sans réel difficultés, mais sur des petits password :)
-- http://nyx-network.com
mpg
Le (on) mercredi 07 novembre 2007 17:37, Jean-Marc Desperrier a écrit (wrote) :
Pour poser les questions autrement, -est-ce possible de savoir que le mot de passe bruteforce est le bon autrement qu'en montant la partition? -est ce possible de connaitre le chiffrement utilise? comment?
Dans une attaque un tant soit peu performante, ce sont normalement des problèmes mineurs. [...] Et pourquoi ne pas chiffrer sans indiquer l'algorithme pour compliquer la vie à l'attaquant ? Parceque ça n'est pas efficace du tout. [...] Toute cette complication, ce risque !, alors qu'il suffit d'ajouter un ou deux caractères au mot de passe pour avoir un meilleur gain de sécurité ? Ca n'a absolument aucun intérêt.
J'avais déjà bien intégré le fait qu'en crypto moderne on considère que tout est public sauf le mot de passe, et que ce dernier est le seul élément qui doit rester inconnu de l'attaquant, donc le seul dont le force détermine la solidité du chiffrement ; on l'entend quand même pas mal répéter (heureusement).
Mais je ne suis pas sûr que j'avais compris aussi clairement pourquoi. Comme tu l'expliques, c'est limpide et très convaincant : je trouve frappante la comparaison entre un caractère de mdp en plus d'un côté, et le fatras incroyable qu'il faut faire de l'autre pour augmenter d'autant le nombre de possibilités, avec tous les risques que ça engendre.
Merci pour cette jolie explication !
Manuel.
Le (on) mercredi 07 novembre 2007 17:37, Jean-Marc Desperrier a écrit
(wrote) :
Pour poser les questions autrement,
-est-ce possible de savoir que le mot de passe bruteforce est
le bon autrement qu'en montant la partition?
-est ce possible de connaitre le chiffrement utilise? comment?
Dans une attaque un tant soit peu performante, ce sont normalement des
problèmes mineurs.
[...]
Et pourquoi ne pas chiffrer sans indiquer l'algorithme pour compliquer
la vie à l'attaquant ? Parceque ça n'est pas efficace du tout.
[...]
Toute cette complication, ce risque !, alors qu'il suffit d'ajouter un
ou deux caractères au mot de passe pour avoir un meilleur gain de
sécurité ? Ca n'a absolument aucun intérêt.
J'avais déjà bien intégré le fait qu'en crypto moderne on considère que tout
est public sauf le mot de passe, et que ce dernier est le seul élément qui
doit rester inconnu de l'attaquant, donc le seul dont le force détermine la
solidité du chiffrement ; on l'entend quand même pas mal répéter
(heureusement).
Mais je ne suis pas sûr que j'avais compris aussi clairement pourquoi. Comme
tu l'expliques, c'est limpide et très convaincant : je trouve frappante la
comparaison entre un caractère de mdp en plus d'un côté, et le fatras
incroyable qu'il faut faire de l'autre pour augmenter d'autant le nombre de
possibilités, avec tous les risques que ça engendre.
Le (on) mercredi 07 novembre 2007 17:37, Jean-Marc Desperrier a écrit (wrote) :
Pour poser les questions autrement, -est-ce possible de savoir que le mot de passe bruteforce est le bon autrement qu'en montant la partition? -est ce possible de connaitre le chiffrement utilise? comment?
Dans une attaque un tant soit peu performante, ce sont normalement des problèmes mineurs. [...] Et pourquoi ne pas chiffrer sans indiquer l'algorithme pour compliquer la vie à l'attaquant ? Parceque ça n'est pas efficace du tout. [...] Toute cette complication, ce risque !, alors qu'il suffit d'ajouter un ou deux caractères au mot de passe pour avoir un meilleur gain de sécurité ? Ca n'a absolument aucun intérêt.
J'avais déjà bien intégré le fait qu'en crypto moderne on considère que tout est public sauf le mot de passe, et que ce dernier est le seul élément qui doit rester inconnu de l'attaquant, donc le seul dont le force détermine la solidité du chiffrement ; on l'entend quand même pas mal répéter (heureusement).
Mais je ne suis pas sûr que j'avais compris aussi clairement pourquoi. Comme tu l'expliques, c'est limpide et très convaincant : je trouve frappante la comparaison entre un caractère de mdp en plus d'un côté, et le fatras incroyable qu'il faut faire de l'autre pour augmenter d'autant le nombre de possibilités, avec tous les risques que ça engendre.
Merci pour cette jolie explication !
Manuel.
Paul Gaborit
À (at) 07 Nov 2007 10:54:57 GMT, Kevin Denis écrivait (wrote):
-est ce possible de connaitre le chiffrement utilise? comment?
Il me semble évident que l'information de la méthode de chiffrement utilisée est stockée quelque part en clair. Ne serait-ce que pour permettre au système de monter le fs (en demandant le bon mot de passe).
Maintenant, d'un point de vue pratique, je ne sais pas comment ni où cryptsetup stocke cette information. Mais, intuitivement, je dirais qu'elle doit l'être dans la partition elle-même : cela permet de transférer facilement cette partition chiffrée d'une machine à l'autre sans avoir besoin de se souvenir à la fois du mot de passe et de la méthode de chiffrement...
De toutes manières, l'obscurité n'est pas une bonne protection. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 07 Nov 2007 10:54:57 GMT,
Kevin Denis <kevin@nowher.invalid> écrivait (wrote):
-est ce possible de connaitre le chiffrement utilise? comment?
Il me semble évident que l'information de la méthode de chiffrement
utilisée est stockée quelque part en clair. Ne serait-ce que pour
permettre au système de monter le fs (en demandant le bon mot de
passe).
Maintenant, d'un point de vue pratique, je ne sais pas comment ni où
cryptsetup stocke cette information. Mais, intuitivement, je dirais
qu'elle doit l'être dans la partition elle-même : cela permet de
transférer facilement cette partition chiffrée d'une machine à l'autre
sans avoir besoin de se souvenir à la fois du mot de passe et de la
méthode de chiffrement...
De toutes manières, l'obscurité n'est pas une bonne protection. ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 07 Nov 2007 10:54:57 GMT, Kevin Denis écrivait (wrote):
-est ce possible de connaitre le chiffrement utilise? comment?
Il me semble évident que l'information de la méthode de chiffrement utilisée est stockée quelque part en clair. Ne serait-ce que pour permettre au système de monter le fs (en demandant le bon mot de passe).
Maintenant, d'un point de vue pratique, je ne sais pas comment ni où cryptsetup stocke cette information. Mais, intuitivement, je dirais qu'elle doit l'être dans la partition elle-même : cela permet de transférer facilement cette partition chiffrée d'une machine à l'autre sans avoir besoin de se souvenir à la fois du mot de passe et de la méthode de chiffrement...
De toutes manières, l'obscurité n'est pas une bonne protection. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Mathieu SEGAUD
Paul Gaborit disait le 11/09/07 que :
À (at) 07 Nov 2007 10:54:57 GMT, Kevin Denis écrivait (wrote):
-est ce possible de connaitre le chiffrement utilise? comment?
Il me semble évident que l'information de la méthode de chiffrement utilisée est stockée quelque part en clair. Ne serait-ce que pour permettre au système de monter le fs (en demandant le bon mot de passe).
Maintenant, d'un point de vue pratique, je ne sais pas comment ni où cryptsetup stocke cette information. Mais, intuitivement, je dirais qu'elle doit l'être dans la partition elle-même : cela permet de transférer facilement cette partition chiffrée d'une machine à l'autre sans avoir besoin de se souvenir à la fois du mot de passe et de la méthode de chiffrement...
De toutes manières, l'obscurité n'est pas une bonne protection. ;-)
hum, dans le cas de cryptsetup, la méthode de chiffrement n'est inscrite nulle part. C'est à l'utilisateur de préciser qd il installe le mapping avec cryptsetup (auquel on précise le chiffrement, le sel s'il y en a un, le mode de chaînage, l'iv....)
dm-crypt fait un mapping brutal bête et méchant d'un bout à l'autre de la partition et ne réserve rien pour des infos quelconques et cryptsetup n'a aucun moyen de deviner le chiffrement.
avec la version luks, c'est différent, mais aucune info de chiffrement n'est stockée nulle part non plus.
-- Mathieu
Paul Gaborit <Paul.Gaborit@invalid.invalid> disait le 11/09/07 que :
À (at) 07 Nov 2007 10:54:57 GMT,
Kevin Denis <kevin@nowher.invalid> écrivait (wrote):
-est ce possible de connaitre le chiffrement utilise? comment?
Il me semble évident que l'information de la méthode de chiffrement
utilisée est stockée quelque part en clair. Ne serait-ce que pour
permettre au système de monter le fs (en demandant le bon mot de
passe).
Maintenant, d'un point de vue pratique, je ne sais pas comment ni où
cryptsetup stocke cette information. Mais, intuitivement, je dirais
qu'elle doit l'être dans la partition elle-même : cela permet de
transférer facilement cette partition chiffrée d'une machine à l'autre
sans avoir besoin de se souvenir à la fois du mot de passe et de la
méthode de chiffrement...
De toutes manières, l'obscurité n'est pas une bonne protection. ;-)
hum, dans le cas de cryptsetup, la méthode de chiffrement n'est
inscrite nulle part. C'est à l'utilisateur de préciser qd il installe
le mapping avec cryptsetup (auquel on précise le chiffrement, le sel
s'il y en a un, le mode de chaînage, l'iv....)
dm-crypt fait un mapping brutal bête et méchant d'un bout à l'autre de
la partition et ne réserve rien pour des infos quelconques
et cryptsetup n'a aucun moyen de deviner le chiffrement.
avec la version luks, c'est différent, mais aucune info de chiffrement
n'est stockée nulle part non plus.
À (at) 07 Nov 2007 10:54:57 GMT, Kevin Denis écrivait (wrote):
-est ce possible de connaitre le chiffrement utilise? comment?
Il me semble évident que l'information de la méthode de chiffrement utilisée est stockée quelque part en clair. Ne serait-ce que pour permettre au système de monter le fs (en demandant le bon mot de passe).
Maintenant, d'un point de vue pratique, je ne sais pas comment ni où cryptsetup stocke cette information. Mais, intuitivement, je dirais qu'elle doit l'être dans la partition elle-même : cela permet de transférer facilement cette partition chiffrée d'une machine à l'autre sans avoir besoin de se souvenir à la fois du mot de passe et de la méthode de chiffrement...
De toutes manières, l'obscurité n'est pas une bonne protection. ;-)
hum, dans le cas de cryptsetup, la méthode de chiffrement n'est inscrite nulle part. C'est à l'utilisateur de préciser qd il installe le mapping avec cryptsetup (auquel on précise le chiffrement, le sel s'il y en a un, le mode de chaînage, l'iv....)
dm-crypt fait un mapping brutal bête et méchant d'un bout à l'autre de la partition et ne réserve rien pour des infos quelconques et cryptsetup n'a aucun moyen de deviner le chiffrement.
avec la version luks, c'est différent, mais aucune info de chiffrement n'est stockée nulle part non plus.
-- Mathieu
Paul Gaborit
À (at) Fri, 09 Nov 2007 12:50:08 +0100, Mathieu SEGAUD écrivait (wrote):
hum, dans le cas de cryptsetup, la méthode de chiffrement n'est inscrite nulle part. C'est à l'utilisateur de préciser qd il installe le mapping avec cryptsetup (auquel on précise le chiffrement, le sel s'il y en a un, le mode de chaînage, l'iv....)
dm-crypt fait un mapping brutal bête et méchant d'un bout à l'autre de la partition et ne réserve rien pour des infos quelconques et cryptsetup n'a aucun moyen de deviner le chiffrement.
avec la version luks, c'est différent, mais aucune info de chiffrement n'est stockée nulle part non plus.
L'info n'est donc pas stockée dans la partition elle-même (c'est idiot mais c'est comme ça). Mais dans ce cas, elle est stockée dans la ligne de commande utilisée par le système ou par l'utilisateur pour monter la partition chiffrée.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 09 Nov 2007 12:50:08 +0100,
Mathieu SEGAUD <matt@regala.cx> écrivait (wrote):
hum, dans le cas de cryptsetup, la méthode de chiffrement n'est
inscrite nulle part. C'est à l'utilisateur de préciser qd il installe
le mapping avec cryptsetup (auquel on précise le chiffrement, le sel
s'il y en a un, le mode de chaînage, l'iv....)
dm-crypt fait un mapping brutal bête et méchant d'un bout à l'autre de
la partition et ne réserve rien pour des infos quelconques
et cryptsetup n'a aucun moyen de deviner le chiffrement.
avec la version luks, c'est différent, mais aucune info de chiffrement
n'est stockée nulle part non plus.
L'info n'est donc pas stockée dans la partition elle-même (c'est idiot
mais c'est comme ça). Mais dans ce cas, elle est stockée dans la ligne
de commande utilisée par le système ou par l'utilisateur pour monter
la partition chiffrée.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 09 Nov 2007 12:50:08 +0100, Mathieu SEGAUD écrivait (wrote):
hum, dans le cas de cryptsetup, la méthode de chiffrement n'est inscrite nulle part. C'est à l'utilisateur de préciser qd il installe le mapping avec cryptsetup (auquel on précise le chiffrement, le sel s'il y en a un, le mode de chaînage, l'iv....)
dm-crypt fait un mapping brutal bête et méchant d'un bout à l'autre de la partition et ne réserve rien pour des infos quelconques et cryptsetup n'a aucun moyen de deviner le chiffrement.
avec la version luks, c'est différent, mais aucune info de chiffrement n'est stockée nulle part non plus.
L'info n'est donc pas stockée dans la partition elle-même (c'est idiot mais c'est comme ça). Mais dans ce cas, elle est stockée dans la ligne de commande utilisée par le système ou par l'utilisateur pour monter la partition chiffrée.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
offworld
avec la version luks, c'est différent, mais aucune info de chiffrement n'est stockée nulle part non plus.
cryptsetup luksDump /dev/xxx renvoi les informations de la partition chiffré.
-- http://nyx-network.com
avec la version luks, c'est différent, mais aucune info de chiffrement
n'est stockée nulle part non plus.
cryptsetup luksDump /dev/xxx renvoi les informations de la partition
chiffré.
