Discussion :

[Le Marlou]

Bonjour, j'ai qq petites questions sur l'utilisation de l'objet Cipher.
Lorsque j'instancie mon objet Cipher :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
final Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding", "BC");

Que faut-il mettre en premier paramètre ("AES/CTR/NoPadding") ? J'ai trouvé sur le net les valeurs possibles mais je n'ai pas bien compris les différences.
Si qq'un m'envoie une donnée chiffrée et que de son coté il a utilisé "AES/CTR/NoPadding" (par exemple) pour chiffrer, est-ce que je dois utiliser la même chose pour mon objet Cipher pour déchiffrer ? Si oui, comment je connais cette valeur ?

J'ai une autre question, lors du chiffrement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
cipher.init(Cipher.ENCRYPT_MODE, key, IvParameter, random);

ou du déchiffrement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
cipher.init(Cipher.DECRYPT_MODE, key, IvParameter, random);

A quoi correspond IvParameter ? J'ai bien trouvé une façon de le générer un utilisation un tableau de bytes aléatoire, basé sur cipher.getBlockSize():

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
byte[] ivBytes = new byte[cipher.getBlockSize()];
random.nextBytes(ivBytes);
IvParameterSpec param = new IvParameterSpec(ivBytes);

mais j'aimerais comprendre à quoi ça cert et comment être sûr d'avoir un paramètre correct ?

Merci d'avance
Le marlou

[Marco46]

Que faut-il mettre en premier paramètre ("AES/CTR/NoPadding") ? J'ai trouvé sur le net les valeurs possibles mais je n'ai pas bien compris les différences.

Le 1er paramètre indique l'algorithme utilisé.

Le 2ème le mode (j'y viendrais plus tard)

Le 3ème la padding (j'y viendrais plus tard)

Si qq'un m'envoie une donnée chiffrée et que de son coté il a utilisé "AES/CTR/NoPadding" (par exemple) pour chiffrer, est-ce que je dois utiliser la même chose pour mon objet Cipher pour déchiffrer ?

Oui.

La méthode init() prendra en paramètre la constante DECRYPT_MODE suivie de la clef de déchiffrement.

Si oui, comment je connais cette valeur ?

Vous devez vous mettre d'accord au préalable. Sinon il peut y avoir un champ dans le certificat X.509 correspondant pour indiquer les préférences de chiffrement.

A quoi correspond IvParameter ? J'ai bien trouvé une façon de le générer un utilisation un tableau de bytes aléatoire, basé sur cipher.getBlockSize():

Alors pour répondre à ça il faut expliquer le 2ème paramètre de ta 1ère question.

Ce qu'on appelle le mode, c'est la manière de chiffrer les données. Il y en a plusieurs, les 2 plus fréquents étant ECB et CBC.

Le problème de ECB c'est que s'il y a des redondances dans les données à chiffrer, par exemple une structure XML, et bien il y aura une redondance dans le résultat du chiffrement ce qui laisse des possibilités d'attaque.

Pour pallier à ça, les grosses têtes en sécurité ont créé le mode CBC, qui lui intervertit les blocs à chiffrer selon une certaine logique (je ne connais pas les détails) pour effacer les redondances possibles dans le résultat du chiffrement.

Or, pour intervertir, il faut bien un point de départ pour le premier bloc. C'est à cela que sert le IvParameter. Il n'est nécessaire QUE pour CBC (ou d'autres modes comparables) mais pas pour ECB. On utilise pour ça la classe IvParameterSpec et une fois instanciée on passe l'instance à la méthode init de Cipher.

Que dire de plus. Le padding :
Un chiffrement par bloc implique de découper les données à chiffrer en bloc de taille fixe dont la taille dépend de l'algorithme. Qui dit longueur de taille fixe dit que si la taille des données à chiffrer n'est pas un multiple de la taille du bloc il y aura un manque. Le padding sert à combler le manque du dernier bloc. Il existe différentes normes de padding, une fréquente étant PKCS#5, il faut donc indiquer au Cipher quel padding utiliser pour chiffrer ou déchiffrer.

[Le Marlou]

Merci pour ta réponse, quand tis dis :

Vous devez vous mettre d'accord au préalable.

Parles-tu juste de l'algorithme, ou bien faut-il aussi se mettre d'accord sur le mode et le padding ?
Ma question est la même pour le paramètre IvParameter ? La valeur doit-elle être la même lors du chiffrement ou du déchiffrement ?

Car, dans mon cas je ne peux pas forcément savoir ce qui a été utilisé lors du chiffrement. En effet, ça se passe comme ceci :
- {A} génère une clé de session aléatoire AES256
- {A} chiffre les données avec cette clé de session
- {A} transmet à {B} dans un 1er flux la clé de session
- {A} transmet à {B} dans un 2eme flux les données chiffrées
- {B} est capable de faire la correspondance entre les flux qu'il reçoit et peut déchiffrer les données d'un flux avec la clé de session correspondante.

Moi je suis {B}, j'ai la clé pour déchiffrer mais je ne sais pas forcément ce que {A} a utilisé comme valeurs (mode, padding, IvParameter) lors de l'init et de l'utilisation de son objet Cipher. D'ailleurs {A} peut très bien avoir utiliser du C# pour chiffrer...

[Marco46]

Parles-tu juste de l'algorithme, ou bien faut-il aussi se mettre d'accord sur le mode et le padding ?

Vous devez vous mettre d'accord sur les 3 composantes, algo, mode et padding.

Ma question est la même pour le paramètre IvParameter ? La valeur doit-elle être la même lors du chiffrement ou du déchiffrement ?

Oui.

La différence entre les modes ECB et CBC est très bien expliquée sur wikipedia avec un exemple simple et compréhensible.

Car, dans mon cas je ne peux pas forcément savoir ce qui a été utilisé lors du chiffrement. En effet, ça se passe comme ceci :
- {A} génère une clé de session aléatoire AES256
- {A} chiffre les données avec cette clé de session
- {A} transmet à {B} dans un 1er flux la clé de session
- {A} transmet à {B} dans un 2eme flux les données chiffrées
- {B} est capable de faire la correspondance entre les flux qu'il reçoit et peut déchiffrer les données d'un flux avec la clé de session correspondante.

C'est quoi cette histoire de 1er flux ? Une utilisation d'un algorithme asymétrique ? (RSA ?)

Dans quel cadre est utilisé ton process, socket ? Mails ?

Dans ce genre de cas standards, les librairies disponibles en Java ont des classes et des méthodes qui gèrent toutes seules cette partie que je qualifierais de "bas niveau".

Moi je suis {B}, j'ai la clé pour déchiffrer mais je ne sais pas forcément ce que {A} a utilisé comme valeurs (mode, padding, IvParameter) lors de l'init et de l'utilisation de son objet Cipher.

Comme tu n'es pas magicien mais juste développeur, tu dois savoir quel algo, quel mode, quel padding et que vecteur d'initialisation ont été utilisés. Seule la clef de session doit demeurer secrète. Les autres informations peuvent être publiques ce n'est pas un problème de sécurité.
Le format PKCS#7, utilisé entre autre pour le chiffrement des mails possède des champs dédiés à ces informations. Comme je te le dis plus haut, des librairies comme BouncyCastle gèrent toutes seules tout ce bouzin. Il suffit de passer en paramètre les données, la config du chiffrement et la clef et la fonction te renvoi un joli MimeBodyPart tout bien formaté comme il faut.

D'ailleurs {A} peut très bien avoir utiliser du C# pour chiffrer...

Le langage de programmation utilisé pour chiffrer n'a pas d'importance. Si un langage fait planter le chiffrement parce qu'il ne respecte pas les normes il ne faut pas l'utiliser. Mais je doute que C#, Java et PHP par exemple soient incompatibles à ce niveau. Ils ont tous des implémentations d'une norme de chiffrement commune (les différents algorithmes) qui sont généralement définis dans des RFC ou des documents fournis par les sociétés/universités éditrices de ces algos (genre RSA Labs pour RSA). Comme pour les mails par exemple. L'API Javamail en java est compatible avec l'API des mails de C# dont je ne connais pas le nom.

[Le Marlou]

ok, merci pour tes réponses, je comprends mieux...
Pour ta question sur l'histoire des flux :
- {A} transmet à {B} dans un 1er flux la clé de session => {A} appelle un web service pour transmettre à {B} certaines infos générales + la clé de session
- {A} transmet à {B} dans un 2eme flux les données chiffrées => {A} appelle un autre web service pour transmettre à {B} les données chiffrées avec la clé envoyée précédemment.
Ca a été conçu comme ça pour que la clé de session ne soit pas envoyée en même temps que les données qu'elle chiffre.
{B} de son coté, grâce à des identifiants présents dans les 2 flux peut associer les données chiffrées à la bonne clé de chiffrement.

[Marco46]

Et le 1er flux il est chiffré comment ?

Pourquoi ne pas utiliser une session TLS plutôt que de réinventer la roue ?