AES, questions et pièges à éviter ?

Il peut arriver que dans le dernier paquet seul le premier octet soit
différent de 0x00. Pouvez-vous me dire si cette particularité est
susceptible d'amoindrir la sécurité des données ? Il me semble que
ce ne soit pas le cas avec AES mais j'aimerais en être "certain".

Je lis en diagonale ton post, mais une petite remarque. Moi aussi j'ai
parfois a traiter des séries de paquets dont les premiers sont
"reconnaissables". J'utilise l'astuce suivante. Comme le dernier octet n'est
jamais pareil, lui, et bien je fais un décalage du paquet de n bits vers la
droite avec réinjection des bits sortis sur la gauche.

Comme le dernier octet n'est jamais pareil (sauf hasard), ça introduit un
peu de hasard dans le premier. Bien sûr faut pas décaler de 8 bits...

Mais si beaucoup de premiers octets sont identiques, le décalage ne sert à
rien car tu repères quand même les 0 toujours au même endroit. Alors, je
ruse. Un paquet sur 3 je décale de1, puis je permute des nibbles, un paquet
sur 2, je décale de 3 et je permute rien, un paquet sur 3 je décale de 1 et
je permute des nibbles. Cela mets bien le bazar et ça planque bien les 0.

Juste une remarque comme ça hein, en même temps, j'ai pas besoin d'être
absolument imperméable à tous les hackers de la planète.

Sinon, solution ultime, j'utilise des tables d'index de permutation qui
changent à chaque paquet.

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Dans l'article <1138530125.249555.255850@g43g2000cwa.googlegroups.com>,
coco_corp@yahoo.fr dit:

Nous souhaitons utiliser AES pour assurer la confidentialité de
certains flux de données dans les fichiers produits par notre
application. Typiquement, ces données sont écrites dans le fichier
par paquets de taille fixe, multiple de 128 bits. J'utilise le mot
paquet pour éviter la confusion avec les blocs de 16 octets d'AES.

Il peut arriver que dans le dernier paquet seul le premier octet soit
différent de 0x00. Pouvez-vous me dire si cette particularité est
susceptible d'amoindrir la sécurité des données ? Il me semble que
ce ne soit pas le cas avec AES mais j'aimerais en être "certain".

Si faiblesse il y avait, ce serait à cause d'un mode d'opération
mal choisi, et non d'une interraction avec AES, pour lequel les
bloc à zero, ou presque à zero, ne sont pas un cas particulier.

Nous envisageons d'utiliser les modes d'opérations CBC ou CTR,
éventuellement CFB.
Avec le mode CTR nous voudrions utiliser une valeur de compteur qui
pour chaque paquet serait dépendante de la position (adresse) de ce
paquet dans le fichier, sachant que des paquets consécutifs peuvent
appartenir à des flux de données différents.

Il y a une attaque. Si c'est un exercise, il est bien trouvé.
Indice: dhryyrf fbag yrf ulcbuÇfrf cbhe yn frphevgr qh zbqr PGE,
rg yrfdhryyrf fbag ivbyrrf (w'ra ibvf qrhk).

Parmi ces trois modes d'opérations en est-il un que nous devrions
privilégier ? Si oui, pourquoi ?

Mauvaise question, et d'importance secondaire. Il faut d'abord
creuser le besoin.
- Confidentialité et/ou intégrité ? Il n'est pas rare que l'on
croie, à tort, que chiffrer assure l'intégrité, et qu'en fait
il soit contre-indiqué de chiffrer (par exemple pour simplifier
la situation au regard des lois qui restreignent le droit de
chiffrer).
- Confidentialité de quoi ? Par exemple, il ne suffit pas de
chiffrer des enregistrements pour cacher à un adversaire quel
enregistrement a été modifié.
- Contraintes de performance ?
- Contraintes opératoires (stockage et mise en oeuvre de la clé) ?


François Grieu

Tout d'abord, merci pour vos réponses

Si faiblesse il y avait, ce serait à cause d'un mode d'opération
mal choisi, et non d'une interraction avec AES, pour lequel les
bloc à zero, ou presque à zero, ne sont pas un cas particulier.

C'est ce que je pensais, merci de l'avoir confirmer.

Avec le mode CTR nous voudrions utiliser une valeur de compteur qui
pour chaque paquet serait dépendante de la position (adresse) de ce
paquet dans le fichier, sachant que des paquets consécutifs peuvent
appartenir à des flux de données différents.
Il y a une attaque. Si c'est un exercise, il est bien trouvé.

Non, ce n'est pas un exercice, c'est un problème concret et bien
réel.

Indice: dhryyrf fbag yrf ulcbuÇfrf cbhe yn frphevgr qh zbqr PGE,
rg yrfdhryyrf fbag ivbyrrf (w'ra ibvf qrhk).

Désolé, mes compétences en cryptanalyse sont très réduites. En
dehors du fait que l'on retrouve 2 fois "dhryyrf fbag" dans ce message,
ça reste très obscur.
S'il existe une attaque possible ou une faiblesse dans cette méthode
de cryptage, pouvez-vous me donner un peu plus d'informations ?

Parmi ces trois modes d'opérations en est-il un que nous devrions
privilégier ? Si oui, pourquoi ?
Mauvaise question, et d'importance secondaire. Il faut d'abord

creuser le besoin.
- Confidentialité et/ou intégrité ? Il n'est pas rare que l'on
croie, à tort, que chiffrer assure l'intégrité, et qu'en fait
il soit contre-indiqué de chiffrer (par exemple pour simplifier
la situation au regard des lois qui restreignent le droit de
chiffrer).

Notre but est d'assurer la confidentialité des données. Une personne
non autorisée qui se trouverait en possession d'un fichier ne doit pas
pouvoir (ou très difficilement) lire les flux de données cryptés.

- Confidentialité de quoi ? Par exemple, il ne suffit pas de
chiffrer des enregistrements pour cacher à un adversaire quel
enregistrement a été modifié.

Dans notre cas, c'est le flux de données qui est important. Même si
l'adversaire peut observer très précisément quel(s)
enregistrement(s) ont été modifiés ou déplacés dans le flux ça
n'est pas suffisamment porteur de sens pour être exploitable.
L'intérêt de telles informations est nul.

- Contraintes de performance ?

Le débit des données à cryptées dépasse rarement 1 ou 2 Mo/s.
Néanmoins le cryptage ne doit pas trop pénaliser les
lectures/écritures puisque la machine à d'autres opérations à
réaliser (calculs ...) et l'utilisateur doit pouvoir accéder à
n'importe quel endroit du flux de données cryptées tout en continuant
à en écrire dans ce même flux.
C'est pourquoi, un cryptage à clés symétriques nous a paru adapté.

- Contraintes opératoires (stockage et mise en oeuvre de la clé) ?

Les clés seront stockées sur un serveur.
L'échange de la clé symétrique entre le serveur et la station de
l'utilisateur se fera sans doute avec un mécaniqme de type SSL.
Le tout se déroulant sur un réseau local où les machines et les
utilisateurs sont supposés "sûrs".


En espérant que ces précisions vous aideront à répondre à mes
questions.


Olivier Cochelin

coco_corp@yahoo.fr wrote:

Indice: dhryyrf fbag yrf ulcbuÇfrf cbhe yn frphevgr qh zbqr PGE,
rg yrfdhryyrf fbag ivbyrrf (w'ra ibvf qrhk).

Désolé, mes compétences en cryptanalyse sont très réduites. En
dehors du fait que l'on retrouve 2 fois "dhryyrf fbag" dans ce
message, ça reste très obscur.

Essaye le rot13...

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Olivier Cochelin a écrit:

Avec le mode CTR nous voudrions utiliser une valeur de compteur qui
pour chaque paquet serait dépendante de la position (adresse) de ce
paquet dans le fichier, sachant que des paquets consécutifs peuvent
appartenir à des flux de données différents.

Il y a une attaque. Si c'est un exercice, il est bien trouvé.

Non, ce n'est pas un exercice, c'est un problème concret et bien
réel.

Indice: dhryyrf fbag yrf ulcburfrf cbhe yn frphevgr qh zbqr PGE,
rg yrfdhryyrf fbag ivbyrrf (w'ra ibvf qrhk).

Désolé, mes compétences en cryptanalyse sont très réduites.

C'est du rot-13. Chaque lettre est remplacée par celle 13 rangs
avant ou après dans l'alphabet. Votre lecteur de news a peut-être
cela dans ses menus. Je disais donc

Indice: quelles sont les hypothèses pour la securité du mode CTR,
et lesquelles sont violées (j'en vois deux).

Les hypothèses violées sont que la valeur du compteur n'est pas
réutilisée à deux endroits du fichier, ni si l'on chiffre une
autre fois.

Quand vous dite "une valeur de compteur qui pour chaque paquet
serait dépendante de la position (adresse)", et que l'on considère
une valeur initiale de compteur égale à l'adresse du paquet, si
l'on connais le clair d'un paquet sauf son premier bloc, on connais
le clair du paquet suivant sauf son dernier bloc.
Bref il faut faire attention au choix de la valeur initiale du
compteur. Ce problème n'arrive pas si on prend le compteur égal
à l'adresse du BLOC dans le fichier (ou ce qui revient au même à
l'adresse paquet multipliée par la taille maximale du paquet,
exprimée en blocs).
Mais reste un autre problème: s'il faut mettre à jour un paquet,
la méthode ci-dessus va réutiliser le même compteur. Donc si
l'adversaire connais l'ancien clair, il connais le nouveau;
et réciproquement (on suppose bien sur que l'adversaire connais
l'ancien et le nouveau chiffré). Un compteur d'écriture associé
à chaque paquet, c'est un pas vers la résolution de ce problème;
reste à considérer l'intégrité de ce compteur.

Parmi ces trois modes d'opérations (CTC, CBC, CFB) en est-il
un que nous devrions privilégier ? Si oui, pourquoi ?

Mauvaise question, et d'importance secondaire. Il faut d'abord
creuser le besoin.
- Confidentialité et/ou intégrité ? Il n'est pas rare que l'on
croie, à tort, que chiffrer assure l'intégrité, et qu'en fait
il soit contre-indiqué de chiffrer (par exemple pour simplifier
la situation au regard des lois qui restreignent le droit de
chiffrer).

Notre but est d'assurer la confidentialité des données. Une personne
non autorisée qui se trouverait en possession d'un fichier ne doit pas
pouvoir (ou très difficilement) lire les flux de données cryptées.

Même en admettant cela, il faut faire attention: adversaire en
possession d'un fichier (chiffré) une seule fois, ou de plusieurs
variantes d'un même fichier ? En possession d'une copie, ou capable
de modifier la version chiffrée en sa possession ? Capable de d'obtenir
certaines données en clair, ou pas ? Ce n'est pas pareil.

Par exemple, une attaque à considérer est que l'adversaire peut
demander à consulter les données nominatives qui lui sont associées
(en invoquant la loi sécurité et liberté) après avoir recopié tout
ou partie des données du paquet d'un tiers dans son propre paquet.
Le chaînage CBC (à clé fixe) est très vulnérable à cette attaque.
CTR avec un compteur convenablement initialisé est moins vulnérable
à cette attaque ci, mais davantage à d'autres tout aussi plausibles.

Noter que si l'on s'assure convenablement de l'intégrité des
données déchiffrées avant de les révéler, ce problème disparait.
Croyez moi: l'intégrité
- est très souvent nécessaire en tant que telle,
- aide en pratique à maintenir la confidentialité,
- participe à la confiance dans le système d'information.

- Confidentialité de quoi ? Par exemple, il ne suffit pas de
chiffrer des enregistrements pour cacher à un adversaire quel
enregistrement a été modifié.

Dans notre cas, c'est le flux de données qui est important. Même si
l'adversaire peut observer très précisément quel(s)
enregistrement(s) ont été modifiés ou déplacés dans le flux ça
n'est pas suffisamment porteur de sens pour être exploitable.
L'intérêt de telles informations est nul.

C'est vous qui savez.

- Contraintes de performance ?

Le débit des données à crypter dépasse rarement 1 ou 2 Mo/s.
Néanmoins le cryptage ne doit pas trop pénaliser les
lectures/écritures puisque la machine à d'autres opérations à
réaliser (calculs ...) et l'utilisateur doit pouvoir accéder à
n'importe quel endroit du flux de données cryptées tout en continuant
à en écrire dans ce même flux.
C'est pourquoi, un cryptage à clés symétriques nous a paru adapté.

2 Mo/s avec AES en logiciel, cela reste du domaine du vraissemblable
avec un CPU de PC moderne, en CTR ou CBC. CFB est moins performant.
CTR a un avantage sur CBC si l'on a plusieurs unités de chiffrement
(plusieurs CPUs par exemple).

- Contraintes opératoires (stockage et mise en oeuvre de la clé) ?

Les clés seront stockées sur un serveur.
L'échange de la clé symétrique entre le serveur et la station de
l'utilisateur se fera sans doute avec un mécaniqme de type SSL.
Le tout se déroulant sur un réseau local où les machines et les
utilisateurs sont supposés "sûrs".

Bien sur; si on commence à voir le mal / le trojan partout, la
cryptographie est impuissante.


François Grieu

Olivier Cochelin a écrit:

Avec le mode CTR nous voudrions utiliser une valeur de compteur qui
pour chaque paquet serait dépendante de la position (adresse) de ce
paquet dans le fichier, sachant que des paquets consécutifs peuvent
appartenir à des flux de données différents.

Il y a une attaque. Si c'est un exercice, il est bien trouvé.

Non, ce n'est pas un exercice, c'est un problème concret et bien
réel.

Indice: dhryyrf fbag yrf ulcburfrf cbhe yn frphevgr qh zbqr PGE,
rg yrfdhryyrf fbag ivbyrrf (w'ra ibvf qrhk).

Désolé, mes compétences en cryptanalyse sont très réduites.

C'est du rot-13. Chaque lettre est remplacée par celle 13 rangs
avant ou après dans l'alphabet. Votre lecteur de news a peut-être
cela dans ses menus. Je disais donc

Indice: quelles sont les hypothèses pour la securité du mode CTR,
et lesquelles sont violées (j'en vois deux).

Les hypothèses violées sont que la valeur du compteur n'est pas
réutilisée à deux endroits du fichier, ni si l'on chiffre une
autre fois.

Quand vous dite "une valeur de compteur qui pour chaque paquet
serait dépendante de la position (adresse)", et que l'on considère
une valeur initiale de compteur égale à l'adresse du paquet, si
l'on connais le clair d'un paquet sauf son premier bloc, on connais
le clair du paquet suivant sauf son dernier bloc.
Bref il faut faire attention au choix de la valeur initiale du
compteur. Ce problème n'arrive pas si on prend le compteur égal
à l'adresse du BLOC dans le fichier (ou ce qui revient au même à
l'adresse paquet multipliée par la taille maximale du paquet,
exprimée en blocs).
Mais reste un autre problème: s'il faut mettre à jour un paquet,
la méthode ci-dessus va réutiliser le même compteur. Donc si
l'adversaire connais l'ancien clair, il connais le nouveau;
et réciproquement (on suppose bien sur que l'adversaire connais
l'ancien et le nouveau chiffré). Un compteur d'écriture associé
à chaque paquet, c'est un pas vers la résolution de ce problème;
reste à considérer l'intégrité de ce compteur.

Parmi ces trois modes d'opérations (CTC, CBC, CFB) en est-il
un que nous devrions privilégier ? Si oui, pourquoi ?

Mauvaise question, et d'importance secondaire. Il faut d'abord
creuser le besoin.
- Confidentialité et/ou intégrité ? Il n'est pas rare que l'on
croie, à tort, que chiffrer assure l'intégrité, et qu'en fait
il soit contre-indiqué de chiffrer (par exemple pour simplifier
la situation au regard des lois qui restreignent le droit de
chiffrer).

Notre but est d'assurer la confidentialité des données. Une personne
non autorisée qui se trouverait en possession d'un fichier ne doit pas
pouvoir (ou très difficilement) lire les flux de données cryptées.

Même en admettant cela, il faut faire attention: adversaire en
possession d'un fichier (chiffré) une seule fois, ou de plusieurs
variantes d'un même fichier ? En possession d'une copie, ou capable
de modifier la version chiffrée en sa possession ? Capable de d'obtenir
certaines données en clair, ou pas ? Ce n'est pas pareil.

Par exemple, une attaque à considérer est que l'adversaire peut
demander à consulter les données nominatives qui lui sont associées
(en invoquant la loi sécurité et liberté) après avoir recopié tout
ou partie des données du paquet d'un tiers dans son propre paquet.
Le chaînage CBC ou CFB (à clé fixe) est très vulnérable à cette
attaque. CTR avec un compteur convenablement initialisé y est moins
vulnérable, mais l'est à d'autres attaques tout aussi plausibles.

Noter que si l'on s'assure convenablement de l'intégrité des
données déchiffrées avant de les révéler, ce problème disparait.
Croyez moi: l'intégrité
- est très souvent nécessaire en tant que telle,
- aide en pratique à maintenir la confidentialité,
- participe à la confiance dans le système d'information.

- Confidentialité de quoi ? Par exemple, il ne suffit pas de
chiffrer des enregistrements pour cacher à un adversaire quel
enregistrement a été modifié.

Dans notre cas, c'est le flux de données qui est important. Même si
l'adversaire peut observer très précisément quel(s)
enregistrement(s) ont été modifiés ou déplacés dans le flux ça
n'est pas suffisamment porteur de sens pour être exploitable.
L'intérêt de telles informations est nul.

C'est vous qui savez.

- Contraintes de performance ?

Le débit des données à crypter dépasse rarement 1 ou 2 Mo/s.
Néanmoins le cryptage ne doit pas trop pénaliser les
lectures/écritures puisque la machine à d'autres opérations à
réaliser (calculs ...) et l'utilisateur doit pouvoir accéder à
n'importe quel endroit du flux de données cryptées tout en continuant
à en écrire dans ce même flux.
C'est pourquoi, un cryptage à clés symétriques nous a paru adapté.

2 Mo/s avec AES en logiciel, cela reste très largement du domaine
du vraissemblable avec un CPU de PC moderne, en CTR, CBC, or CFB.
CTR a un avantage sur ce plan si l'on a plusieurs unités de
chiffrement (plusieurs CPUs par exemple).

- Contraintes opératoires (stockage et mise en oeuvre de la clé) ?

Les clés seront stockées sur un serveur.
L'échange de la clé symétrique entre le serveur et la station de
l'utilisateur se fera sans doute avec un mécaniqme de type SSL.
Le tout se déroulant sur un réseau local où les machines et les
utilisateurs sont supposés "sûrs".

Bien sur; si on commence à voir le mal / le trojan partout, la
cryptographie est impuissante.


François Grieu