en cryptographie symétrique on dissocie souvent le chiffrement et
l'authentification/intégrité :
chiffrement(texte en clair) + MAC(texte en clair)
pourquoi ne pas faire directement:
chiffrement(texte en clair + SHA(texte en clair))
(le chiffrement étant en mode CBC, on peut aussi ajouter un peu de sel
aléatoire avant le SHA...)
on a bien confidentialité, authentification et intégrité
existe t il des attaques contre cela?
des articles disponibles?
(les attaques par collisions de Preneel et Oorschot ne s'aplique pas
dans ce cas non?)
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
pornin
According to Brennos :
pourquoi ne pas faire directement: chiffrement(texte en clair + SHA(texte en clair)) (le chiffrement étant en mode CBC, on peut aussi ajouter un peu de sel aléatoire avant le SHA...) on a bien confidentialité, authentification et intégrité
Ça marche avec un système de chiffrement par blocs utilisé en mode CBC. Mais ça ne marche pas avec, par exemple, un chiffrement RC4 : le contrôle d'intégrité est alors réduit à néant (exercice laissé au lecteur).
De façon plus générale, séparer le MAC du chiffrement facilite les preuves de sécurité, et permet aussi de doser les propriétés de sécurité voulues : par exemple, si je veux un protocole ou je veux donner à deux personnes (A et B) le pouvoir de lire les données, mais seulement à une des deux personnes (A) le pouvoir de les modifier, je peux le faire avec un MAC séparé : je donne la clé de chiffrement à A et B, mais la clé de MAC à A seulement. Avec un chiffrement+MAC en une seule opération, je ne peux pas faire ça. Je peux aussi me retrouver dans un pays qui exige que les clés de chiffrement ne dépassent pas 40 bits ; avec un MAC séparé, je peux conserver un contrôle d'intégrité solide.
--Thomas Pornin
According to Brennos <crecy_1346@hotmail.com>:
pourquoi ne pas faire directement:
chiffrement(texte en clair + SHA(texte en clair))
(le chiffrement étant en mode CBC, on peut aussi ajouter un peu de sel
aléatoire avant le SHA...)
on a bien confidentialité, authentification et intégrité
Ça marche avec un système de chiffrement par blocs utilisé en mode
CBC. Mais ça ne marche pas avec, par exemple, un chiffrement RC4 :
le contrôle d'intégrité est alors réduit à néant (exercice laissé
au lecteur).
De façon plus générale, séparer le MAC du chiffrement facilite les
preuves de sécurité, et permet aussi de doser les propriétés de sécurité
voulues : par exemple, si je veux un protocole ou je veux donner à deux
personnes (A et B) le pouvoir de lire les données, mais seulement à une
des deux personnes (A) le pouvoir de les modifier, je peux le faire avec
un MAC séparé : je donne la clé de chiffrement à A et B, mais la clé de
MAC à A seulement. Avec un chiffrement+MAC en une seule opération, je ne
peux pas faire ça. Je peux aussi me retrouver dans un pays qui exige que
les clés de chiffrement ne dépassent pas 40 bits ; avec un MAC séparé,
je peux conserver un contrôle d'intégrité solide.
pourquoi ne pas faire directement: chiffrement(texte en clair + SHA(texte en clair)) (le chiffrement étant en mode CBC, on peut aussi ajouter un peu de sel aléatoire avant le SHA...) on a bien confidentialité, authentification et intégrité
Ça marche avec un système de chiffrement par blocs utilisé en mode CBC. Mais ça ne marche pas avec, par exemple, un chiffrement RC4 : le contrôle d'intégrité est alors réduit à néant (exercice laissé au lecteur).
De façon plus générale, séparer le MAC du chiffrement facilite les preuves de sécurité, et permet aussi de doser les propriétés de sécurité voulues : par exemple, si je veux un protocole ou je veux donner à deux personnes (A et B) le pouvoir de lire les données, mais seulement à une des deux personnes (A) le pouvoir de les modifier, je peux le faire avec un MAC séparé : je donne la clé de chiffrement à A et B, mais la clé de MAC à A seulement. Avec un chiffrement+MAC en une seule opération, je ne peux pas faire ça. Je peux aussi me retrouver dans un pays qui exige que les clés de chiffrement ne dépassent pas 40 bits ; avec un MAC séparé, je peux conserver un contrôle d'intégrité solide.
--Thomas Pornin
crecy_1346
De façon plus générale, séparer le MAC du chiffrement facilite les preuves de sécurité, et permet aussi de doser les propriétés de sécurité voulues : par exemple, si je veux un protocole ou je veux donner à deux personnes (A et B) le pouvoir de lire les données, mais seulement à une des deux personnes (A) le pouvoir de les modifier, je peux le faire avec un MAC séparé : je donne la clé de chiffrement à A et B, mais la clé de MAC à A seulement. Avec un chiffrement+MAC en une seule opération, je ne peux pas faire ça. Je peux aussi me retrouver dans un pays qui exige que les clés de chiffrement ne dépassent pas 40 bits ; avec un MAC séparé, je peux conserver un contrôle d'intégrité solide.
--Thomas Pornin
on est d'accord que cela rajoute des possibilités, mais si on n'en a pas l'utilité dans un système donné cela rajoute de la complexité et du temps de calcul inutilement
pour eviter cela je vois 3 solutions:
helix ou AES-CCM chiffrement block CBC(texte en clair + ?salt? + SHA(texte en clair))
et si on utilise un bete CRC au lieu d'un SHA mais assez grand (par ex CRC de 128 bits), si le chiffrement block CBC est sur et que le salt est à chaque fois différents et de très bonne qualité (iodé et fluoré)?
De façon plus générale, séparer le MAC du chiffrement facilite les
preuves de sécurité, et permet aussi de doser les propriétés de sécurité
voulues : par exemple, si je veux un protocole ou je veux donner à deux
personnes (A et B) le pouvoir de lire les données, mais seulement à une
des deux personnes (A) le pouvoir de les modifier, je peux le faire avec
un MAC séparé : je donne la clé de chiffrement à A et B, mais la clé de
MAC à A seulement. Avec un chiffrement+MAC en une seule opération, je ne
peux pas faire ça. Je peux aussi me retrouver dans un pays qui exige que
les clés de chiffrement ne dépassent pas 40 bits ; avec un MAC séparé,
je peux conserver un contrôle d'intégrité solide.
--Thomas Pornin
on est d'accord que cela rajoute des possibilités, mais si on n'en a
pas l'utilité dans un système donné cela rajoute de la complexité et
du temps de calcul inutilement
pour eviter cela je vois 3 solutions:
helix ou AES-CCM
chiffrement block CBC(texte en clair + ?salt? + SHA(texte en clair))
et si on utilise un bete CRC au lieu d'un SHA mais assez grand (par ex
CRC de 128 bits), si le chiffrement block CBC est sur et que le salt
est à chaque fois différents et de très bonne qualité (iodé et
fluoré)?
De façon plus générale, séparer le MAC du chiffrement facilite les preuves de sécurité, et permet aussi de doser les propriétés de sécurité voulues : par exemple, si je veux un protocole ou je veux donner à deux personnes (A et B) le pouvoir de lire les données, mais seulement à une des deux personnes (A) le pouvoir de les modifier, je peux le faire avec un MAC séparé : je donne la clé de chiffrement à A et B, mais la clé de MAC à A seulement. Avec un chiffrement+MAC en une seule opération, je ne peux pas faire ça. Je peux aussi me retrouver dans un pays qui exige que les clés de chiffrement ne dépassent pas 40 bits ; avec un MAC séparé, je peux conserver un contrôle d'intégrité solide.
--Thomas Pornin
on est d'accord que cela rajoute des possibilités, mais si on n'en a pas l'utilité dans un système donné cela rajoute de la complexité et du temps de calcul inutilement
pour eviter cela je vois 3 solutions:
helix ou AES-CCM chiffrement block CBC(texte en clair + ?salt? + SHA(texte en clair))
et si on utilise un bete CRC au lieu d'un SHA mais assez grand (par ex CRC de 128 bits), si le chiffrement block CBC est sur et que le salt est à chaque fois différents et de très bonne qualité (iodé et fluoré)?
Christophe Devine
Brennos wrote:
on est d'accord que cela rajoute des possibilités, mais si on n'en a pas l'utilité dans un système donné cela rajoute de la complexité et du temps de calcul inutilement
Il faut noter que le fait de chiffrer puis d'ajouter le MAC du chiffré est théoriquement plus sûr que d'authentifier d'abord, et de chiffrer ensuite. Voir pour plus de détails:
http://citeseer.nj.nec.com/krawczyk01order.html
-- Christophe Devine
Brennos <crecy_1346@hotmail.com> wrote:
on est d'accord que cela rajoute des possibilités, mais si on n'en a
pas l'utilité dans un système donné cela rajoute de la complexité et
du temps de calcul inutilement
Il faut noter que le fait de chiffrer puis d'ajouter le MAC du
chiffré est théoriquement plus sûr que d'authentifier d'abord,
et de chiffrer ensuite. Voir pour plus de détails:
on est d'accord que cela rajoute des possibilités, mais si on n'en a pas l'utilité dans un système donné cela rajoute de la complexité et du temps de calcul inutilement
Il faut noter que le fait de chiffrer puis d'ajouter le MAC du chiffré est théoriquement plus sûr que d'authentifier d'abord, et de chiffrer ensuite. Voir pour plus de détails:
http://citeseer.nj.nec.com/krawczyk01order.html
-- Christophe Devine
Francois Grieu
Dans l'article <bo692r$1fa9$, (Thomas Pornin) dit:
According to Brennos :
pourquoi ne pas faire directement: chiffrement(texte en clair + SHA(texte en clair)) (le chiffrement étant en mode CBC, on peut aussi ajouter un peu de sel aléatoire avant le SHA...) on a bien confidentialité, authentification et intégrité
Ça marche avec un système de chiffrement par blocs utilisé en mode CBC. Mais ça ne marche pas avec, par exemple, un chiffrement RC4 : le contrôle d'intégrité est alors réduit à néant (exercice laissé au lecteur).
Le lecteur vérifiera aussi
- que si l'attaquant est à même de choisir ne serais-ce que très partiellement un message signé (par exemple: un champs inutilisé compte tenu du format du fichier), il lui est possible de compromettre l'intégrité (principe: il construit d'abord un message dont le clair et le chiffré sont connus sauf pour le hash, puis calcule le hash, et obtient le chiffré du hash par une requète à message choisi qui va bien)
- que même en excluant le clair partiellement choisi, la taille de bloc de l'algorithme de chiffrement est à prendre en considération dans l'analyse de sécurité; ce qui n'est pas bon bon signe.
François Grieu
Dans l'article <bo692r$1fa9$2@biggoron.nerim.net>,
pornin@nerim.net (Thomas Pornin) dit:
According to Brennos <crecy_1346@hotmail.com>:
pourquoi ne pas faire directement:
chiffrement(texte en clair + SHA(texte en clair))
(le chiffrement étant en mode CBC, on peut aussi ajouter un peu de sel
aléatoire avant le SHA...)
on a bien confidentialité, authentification et intégrité
Ça marche avec un système de chiffrement par blocs utilisé en mode
CBC. Mais ça ne marche pas avec, par exemple, un chiffrement RC4 :
le contrôle d'intégrité est alors réduit à néant (exercice laissé
au lecteur).
Le lecteur vérifiera aussi
- que si l'attaquant est à même de choisir ne serais-ce que très
partiellement un message signé (par exemple: un champs inutilisé
compte tenu du format du fichier), il lui est possible de
compromettre l'intégrité (principe: il construit d'abord un
message dont le clair et le chiffré sont connus sauf pour le hash,
puis calcule le hash, et obtient le chiffré du hash par une requète
à message choisi qui va bien)
- que même en excluant le clair partiellement choisi, la taille
de bloc de l'algorithme de chiffrement est à prendre en
considération dans l'analyse de sécurité; ce qui n'est pas bon
bon signe.
Dans l'article <bo692r$1fa9$, (Thomas Pornin) dit:
According to Brennos :
pourquoi ne pas faire directement: chiffrement(texte en clair + SHA(texte en clair)) (le chiffrement étant en mode CBC, on peut aussi ajouter un peu de sel aléatoire avant le SHA...) on a bien confidentialité, authentification et intégrité
Ça marche avec un système de chiffrement par blocs utilisé en mode CBC. Mais ça ne marche pas avec, par exemple, un chiffrement RC4 : le contrôle d'intégrité est alors réduit à néant (exercice laissé au lecteur).
Le lecteur vérifiera aussi
- que si l'attaquant est à même de choisir ne serais-ce que très partiellement un message signé (par exemple: un champs inutilisé compte tenu du format du fichier), il lui est possible de compromettre l'intégrité (principe: il construit d'abord un message dont le clair et le chiffré sont connus sauf pour le hash, puis calcule le hash, et obtient le chiffré du hash par une requète à message choisi qui va bien)
- que même en excluant le clair partiellement choisi, la taille de bloc de l'algorithme de chiffrement est à prendre en considération dans l'analyse de sécurité; ce qui n'est pas bon bon signe.
