imaginons Alice et Bob. Lorsque ces deux personnes sont présentes,
elles doivent ouvrir un coffre (une authentification).
Bob a une clé. Alice en a une.
Existe t'il un moyen simple pour concaténer les deux clés de manière
securisée afin que leur concaténation ouvre le coffre, mais que ni Bob
ni Alice avec chacun leur clé puisse l'ouvrir? Bien entendu, Alice
et Bob sont concurrents et leur clé ne doit pas permettre de leur
donner un moyen simple (ou faciliter) l'ouverture du coffre.
Les problématiques de remplacement de clé ne sont pas abordées. Les
problématiques de révocation non plus.
J'ai a dispo un toolkit UNIX de base (openssl ou n'importe quel
programme C).
A froid, je dirais que si je demande à chacun une clé suffisement
longue, la réunion des deux est suffisante, mais je passe peut-être
à côté de quelque chose.
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
Thomas Pornin
According to Kevin Denis :
A froid, je dirais que si je demande à chacun une clé suffisement longue, la réunion des deux est suffisante, mais je passe peut-être à côté de quelque chose.
Dit comme ça, oui, ça semble suffisant.
Pour avoir plus de marge quant à la taille des clés, on peut faire un hachage. Si par exemple le chiffrement est conditionné par une clé de 256 bits, alors on donne à Alice une clé A "assez grande", et à Bob une clé B également de grande taille, et on utilise comme clé de chiffrement le résultat de SHA-256(A || B) (où '||' signifie concaténation). Comme ça on est libre sur les tailles des clés A et B.
Ça s'étend à autant de participant qu'on veut, avec comme contrainte qu'il faut que tous participent. Ça peut être un problème si on partage la clé entre dix personnes, et que l'un des dix passe sous un bus. Pour un traitement plus général, avec un seuil (par exemple, partage entre dix personnes, tel que sept suffisent pour ouvrir), on utilise le protocole de Shamir : http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing
--Thomas Pornin
According to Kevin Denis <kevin@alinto.comNOSPAM>:
A froid, je dirais que si je demande à chacun une clé suffisement
longue, la réunion des deux est suffisante, mais je passe peut-être
à côté de quelque chose.
Dit comme ça, oui, ça semble suffisant.
Pour avoir plus de marge quant à la taille des clés, on peut faire un
hachage. Si par exemple le chiffrement est conditionné par une clé de
256 bits, alors on donne à Alice une clé A "assez grande", et à Bob une
clé B également de grande taille, et on utilise comme clé de chiffrement
le résultat de SHA-256(A || B) (où '||' signifie concaténation). Comme
ça on est libre sur les tailles des clés A et B.
Ça s'étend à autant de participant qu'on veut, avec comme contrainte
qu'il faut que tous participent. Ça peut être un problème si on partage
la clé entre dix personnes, et que l'un des dix passe sous un bus. Pour
un traitement plus général, avec un seuil (par exemple, partage entre
dix personnes, tel que sept suffisent pour ouvrir), on utilise le
protocole de Shamir :
http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing
A froid, je dirais que si je demande à chacun une clé suffisement longue, la réunion des deux est suffisante, mais je passe peut-être à côté de quelque chose.
Dit comme ça, oui, ça semble suffisant.
Pour avoir plus de marge quant à la taille des clés, on peut faire un hachage. Si par exemple le chiffrement est conditionné par une clé de 256 bits, alors on donne à Alice une clé A "assez grande", et à Bob une clé B également de grande taille, et on utilise comme clé de chiffrement le résultat de SHA-256(A || B) (où '||' signifie concaténation). Comme ça on est libre sur les tailles des clés A et B.
Ça s'étend à autant de participant qu'on veut, avec comme contrainte qu'il faut que tous participent. Ça peut être un problème si on partage la clé entre dix personnes, et que l'un des dix passe sous un bus. Pour un traitement plus général, avec un seuil (par exemple, partage entre dix personnes, tel que sept suffisent pour ouvrir), on utilise le protocole de Shamir : http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing
--Thomas Pornin
Manuel Pégourié-Gonnard
Kevin Denis scripsit :
imaginons Alice et Bob. Lorsque ces deux personnes sont présentes, elles doivent ouvrir un coffre (une authentification). Bob a une clé. Alice en a une.
Existe t'il un moyen simple pour concaténer les deux clés de manière securisée afin que leur concaténation ouvre le coffre, mais que ni Bob ni Alice avec chacun leur clé puisse l'ouvrir? Bien entendu, Alice et Bob sont concurrents et leur clé ne doit pas permettre de leur donner un moyen simple (ou faciliter) l'ouverture du coffre.
J'imagine que tu veux dire « combiner » plutôt que « concaténer » ? En effet, concaténer, c'est très spécifique. On pourrait effectivement donner la moitié de la clé à chacun, mais du coup, pour chacun des deux la recherche de la clé complète est deux fois plus facile (dans le sens que l'entropie est divisée par deux, donc la taille de l'espace de recherche des clés est élevée à la puissance 1/2) que pour un attaquant extérieur.
Ce n'est pas terrible, et il y a moyen de faire en sorte que la connaissance d'un des deux secrets (détenus par Alice et par Bob) ne donne, seule, aucune information sur la clé (donc rechercher la clé serait aussi difficile pour Alice ou Bob que pour n'importe qui), bien que leur association permette de retrouver la clé.
Le principe est simple. On gènère une clé pour « comme d'habitude ». On génére une suite d'octets aléatoires de même taille que la clé. On donne à Alice cette suite d'octets, et à Bob le résultat du XOR bit à bit ce cette quite et de la clé. Si on fait un XOR du secret d'Alice et du secret de Bob, on retrouve la clé. Mais, pris indépendament, aucun des deux secrets ne donne d'information sur la clé (c'est particulièrement clair pour celui d'Alice, et cela s'en déduit pour celui de Bob car les deux jouent un rôle symétrique).
On peut généraliser à N secrets qui ensemble permettent de retrouver la clé, mais tels que la connaissance de N-1 d'entre eux ne donne pas la moindre information. On peut aussi avoir N secrets de sorte que M quelconques d'entre eux donnent la clé, mais M-1 quelconques ne donnent aucune information sur la clé. Cf
http://en.wikipedia.org/wiki/Secret_sharing
pour quelques techniques classiques.
A froid, je dirais que si je demande à chacun une clé suffisement longue, la réunion des deux est suffisante, mais je passe peut-être à côté de quelque chose.
Bah, on pourrait dire en effet que si tu considères qu'une taille de clé T est suffisante pour protéger ton secret, alors il suiffit de générer une clé de taille 2T et d'en donner « naïvement » la moitié à chacun des deux acteurs. Pour le grand public, la difficulté de l'attque est donnée par le taille de clé 2T qui est plus que suffisante, pour chacun des participants, elle est donnée par T, dont on a supposé que c'était une taille suffisante.
Le problème de cette stratégqie est qu'elle ne passe pas à l'échelle sur le nombre de participants. Vu que la stratégie exposée ci-dessus n'est pas plus compliquée, elle est sans doute très préférable.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Kevin Denis scripsit :
imaginons Alice et Bob. Lorsque ces deux personnes sont présentes,
elles doivent ouvrir un coffre (une authentification).
Bob a une clé. Alice en a une.
Existe t'il un moyen simple pour concaténer les deux clés de manière
securisée afin que leur concaténation ouvre le coffre, mais que ni Bob
ni Alice avec chacun leur clé puisse l'ouvrir? Bien entendu, Alice
et Bob sont concurrents et leur clé ne doit pas permettre de leur
donner un moyen simple (ou faciliter) l'ouverture du coffre.
J'imagine que tu veux dire « combiner » plutôt que « concaténer » ? En
effet, concaténer, c'est très spécifique. On pourrait effectivement
donner la moitié de la clé à chacun, mais du coup, pour chacun des deux
la recherche de la clé complète est deux fois plus facile (dans le sens
que l'entropie est divisée par deux, donc la taille de l'espace de
recherche des clés est élevée à la puissance 1/2) que pour un attaquant
extérieur.
Ce n'est pas terrible, et il y a moyen de faire en sorte que la
connaissance d'un des deux secrets (détenus par Alice et par Bob) ne
donne, seule, aucune information sur la clé (donc rechercher la clé
serait aussi difficile pour Alice ou Bob que pour n'importe qui), bien
que leur association permette de retrouver la clé.
Le principe est simple. On gènère une clé pour « comme d'habitude ». On
génére une suite d'octets aléatoires de même taille que la clé. On donne
à Alice cette suite d'octets, et à Bob le résultat du XOR bit à bit ce
cette quite et de la clé. Si on fait un XOR du secret d'Alice et du
secret de Bob, on retrouve la clé. Mais, pris indépendament, aucun des
deux secrets ne donne d'information sur la clé (c'est particulièrement
clair pour celui d'Alice, et cela s'en déduit pour celui de Bob car les
deux jouent un rôle symétrique).
On peut généraliser à N secrets qui ensemble permettent de retrouver la
clé, mais tels que la connaissance de N-1 d'entre eux ne donne pas la
moindre information. On peut aussi avoir N secrets de sorte que M
quelconques d'entre eux donnent la clé, mais M-1 quelconques ne donnent
aucune information sur la clé. Cf
http://en.wikipedia.org/wiki/Secret_sharing
pour quelques techniques classiques.
A froid, je dirais que si je demande à chacun une clé suffisement
longue, la réunion des deux est suffisante, mais je passe peut-être
à côté de quelque chose.
Bah, on pourrait dire en effet que si tu considères qu'une taille de clé
T est suffisante pour protéger ton secret, alors il suiffit de générer
une clé de taille 2T et d'en donner « naïvement » la moitié à chacun des
deux acteurs. Pour le grand public, la difficulté de l'attque est donnée
par le taille de clé 2T qui est plus que suffisante, pour chacun des
participants, elle est donnée par T, dont on a supposé que c'était une
taille suffisante.
Le problème de cette stratégqie est qu'elle ne passe pas à l'échelle sur
le nombre de participants. Vu que la stratégie exposée ci-dessus n'est
pas plus compliquée, elle est sans doute très préférable.
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
imaginons Alice et Bob. Lorsque ces deux personnes sont présentes, elles doivent ouvrir un coffre (une authentification). Bob a une clé. Alice en a une.
Existe t'il un moyen simple pour concaténer les deux clés de manière securisée afin que leur concaténation ouvre le coffre, mais que ni Bob ni Alice avec chacun leur clé puisse l'ouvrir? Bien entendu, Alice et Bob sont concurrents et leur clé ne doit pas permettre de leur donner un moyen simple (ou faciliter) l'ouverture du coffre.
J'imagine que tu veux dire « combiner » plutôt que « concaténer » ? En effet, concaténer, c'est très spécifique. On pourrait effectivement donner la moitié de la clé à chacun, mais du coup, pour chacun des deux la recherche de la clé complète est deux fois plus facile (dans le sens que l'entropie est divisée par deux, donc la taille de l'espace de recherche des clés est élevée à la puissance 1/2) que pour un attaquant extérieur.
Ce n'est pas terrible, et il y a moyen de faire en sorte que la connaissance d'un des deux secrets (détenus par Alice et par Bob) ne donne, seule, aucune information sur la clé (donc rechercher la clé serait aussi difficile pour Alice ou Bob que pour n'importe qui), bien que leur association permette de retrouver la clé.
Le principe est simple. On gènère une clé pour « comme d'habitude ». On génére une suite d'octets aléatoires de même taille que la clé. On donne à Alice cette suite d'octets, et à Bob le résultat du XOR bit à bit ce cette quite et de la clé. Si on fait un XOR du secret d'Alice et du secret de Bob, on retrouve la clé. Mais, pris indépendament, aucun des deux secrets ne donne d'information sur la clé (c'est particulièrement clair pour celui d'Alice, et cela s'en déduit pour celui de Bob car les deux jouent un rôle symétrique).
On peut généraliser à N secrets qui ensemble permettent de retrouver la clé, mais tels que la connaissance de N-1 d'entre eux ne donne pas la moindre information. On peut aussi avoir N secrets de sorte que M quelconques d'entre eux donnent la clé, mais M-1 quelconques ne donnent aucune information sur la clé. Cf
http://en.wikipedia.org/wiki/Secret_sharing
pour quelques techniques classiques.
A froid, je dirais que si je demande à chacun une clé suffisement longue, la réunion des deux est suffisante, mais je passe peut-être à côté de quelque chose.
Bah, on pourrait dire en effet que si tu considères qu'une taille de clé T est suffisante pour protéger ton secret, alors il suiffit de générer une clé de taille 2T et d'en donner « naïvement » la moitié à chacun des deux acteurs. Pour le grand public, la difficulté de l'attque est donnée par le taille de clé 2T qui est plus que suffisante, pour chacun des participants, elle est donnée par T, dont on a supposé que c'était une taille suffisante.
Le problème de cette stratégqie est qu'elle ne passe pas à l'échelle sur le nombre de participants. Vu que la stratégie exposée ci-dessus n'est pas plus compliquée, elle est sans doute très préférable.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
