Java 8, chiffrement AES, encodage, Windows 10, invite de commande, batch et IDE
Résolu/Fermé
A voir également:
- Java 8, chiffrement AES, encodage, Windows 10, invite de commande, batch et IDE
- Invite de commande - Guide
- Clé windows 8 - Guide
- Windows 10 gratuit - Accueil - Mise à jour
- Winrar 64 bits windows 10 - Télécharger - Compression & Décompression
- Waptrick java football - Télécharger - Jeux vidéo
1 réponse
KX
Messages postés
16752
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
31 août 2024
3 019
24 avril 2020 à 10:49
24 avril 2020 à 10:49
Bonjour,
Effectivement tu t'es pris les pieds dans l'encodage.
Prenons une analogie avec les langues :
Ton problème, c'est que tu demandes à Eclipse de faire une traduction du français vers l'anglais, puis à l'invite de commandes de traduire de l'allemand vers le français.
Or le texte en anglais ce n'est pas de l'allemand ! Donc la traduction de l'allemand à partir du texte anglais ça ne peut pas donner un français correct...
Dans ton code, le problème se situe ici au niveau de Encrypt
Ci dessous un petit code d'exemple pour comprendre : peu importe l'encodage choisi si on utilises le même lors de la conversion String/byte[] et byte[]/String ça fonctionnera, mais dès qu'on mélange les encodages, ça fera un peu n'importe quoi :
Pour corriger ton code, il faut donc que tu imposes un encodage (peu importe lequel) pour que la conversion String/byte[] et byte[]/String soit cohérente.
Effectivement tu t'es pris les pieds dans l'encodage.
Prenons une analogie avec les langues :
- Eclipse fait une traduction du français vers l'anglais puis de l'anglais vers le français, c'est bon.
- L'invite de commandes fait une traduction du français vers l'allemand puis de l'allemand vers le français, donc c'est bon aussi.
Ton problème, c'est que tu demandes à Eclipse de faire une traduction du français vers l'anglais, puis à l'invite de commandes de traduire de l'allemand vers le français.
Or le texte en anglais ce n'est pas de l'allemand ! Donc la traduction de l'allemand à partir du texte anglais ça ne peut pas donner un français correct...
Dans ton code, le problème se situe ici au niveau de Encrypt
_arguments[1].getBytes()et de Decypher
new String(...), car ces méthodes prennent une valeur d'encodage par défaut, or si celle-ci est différente entre le chiffrement et le déchiffrement alors ça ne fonctionnera pas.
Ci dessous un petit code d'exemple pour comprendre : peu importe l'encodage choisi si on utilises le même lors de la conversion String/byte[] et byte[]/String ça fonctionnera, mais dès qu'on mélange les encodages, ça fera un peu n'importe quoi :
import java.nio.charset.Charset;
import java.util.Arrays;
public class Test {
public static void main(String[] args) throws Exception {
Charset c1 = Charset.forName("windows-1252");
Charset c2 = Charset.forName("UTF-8");
String text = "Aïe";
System.out.println("text"); // Aïe
byte[] textC1 = text.getBytes(c1);
System.out.println("c1\t" + Arrays.toString(textC1)); // 65, -17, 101
byte[] textC2 = text.getBytes(c2);
System.out.println("c2\t" + Arrays.toString(textC2)); // 65, -61, -81, 101
String textC1C1 = new String(textC1, c1);
System.out.println("c1c1\t" + textC1C1); // Aïe
String textC2C2 = new String(textC2, c2);
System.out.println("c2c2\t" + textC2C2); // Aïe
String textC1C2 = new String(textC1, c2);
System.out.println("c1c2\t" + textC1C2); // A?e
String textC2C1 = new String(textC2, c1);
System.out.println("c2c1\t" + textC2C1); // Aïe
}
}
Pour corriger ton code, il faut donc que tu imposes un encodage (peu importe lequel) pour que la conversion String/byte[] et byte[]/String soit cohérente.
24 avril 2020 à 15:25
Je ne vois pas trop où imposer l'encodage. En fait, a priori il était censé l'être car il me semble que Java compile toujours en encodant par défaut les caractères dans l'encodage par défaut du système, donc tout dans mon cas aurait été "censé" (dans mon cerveau) être en cp1252 puisque je n'ai rien précisé nul part.
D'autre part et surtout, pourquoi diable l'invite de commande (oublions l'exécution sur Eclipse qui "cache" souvent quelques bugs pourtant existants "grâce" à ses propres paramètres d'exécution) ne se rend compte de rien non plus ? Mon desarroi vient du fait que la même commande :
java -jar Encrypt.jar "cle" "message"
donne un résultat différent si elle est tapée manuellement sur l'invite de commande ou si c'est un batch (tapé manuellement) qui la "tape", l'encodage du fichier batch lui-même n'étant pas en cause, puisque changer sa valeur ne produit aucune différence d'aucune sorte.
Je sèche...
24 avril 2020 à 15:33
Il faut reprendre mon code d'exemple, au lieu d'utiliser j'ai utilisé , de même dans l'autre sens au lieu d'utiliser j'ai utilisé .
"Imposer l'encodage" c'est s'assurer que le Charset utilisé dans un sens sera bien le même que dans l'autre sens, ce qui est impossible à garantir si ces deux opérations sont faites par des programmes différents, qui ont de toute évidence des Charset par défaut différent (tu peux afficher et voir sa valeur).
Remarque : attention aussi à l'encodage du fichier batch, s'il est écrit en UTF-8 (par exemple), il faudra le lire en UTF-8, alors que si tu écris en ligne de commande en windows-1252, il faudra le lire en windows-1252...
Modifié le 24 avril 2020 à 19:05
Mais il n'y a pas d'autre sens... :
import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; import java.security.NoSuchAlgorithmException; import java.util.Base64; import javax.crypto.NoSuchPaddingException; import javax.crypto.BadPaddingException; import javax.crypto.IllegalBlockSizeException; import java.security.InvalidKeyException; class Encrypt { public static void main(String _arguments[]) { try { Cipher _encrypt = Cipher.getInstance("AES"); _encrypt.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(Base64.getUrlDecoder().decode(_arguments[0]), "AES")); System.out.println(Base64.getEncoder().encodeToString(_encrypt.doFinal(_arguments[1].getBytes()))); } catch(NoSuchAlgorithmException | NoSuchPaddingException | InvalidKeyException | IllegalBlockSizeException | BadPaddingException _e) { System.err.println("Erreur lors du chiffrement : ".concat(_e.getMessage())); } } }Je parle de ce programme et de ce programme seul, les autres n'étaient là que pour tester l'ensemble éventuellement. Mais il est aussi bien indépendant et c'est donc en l'exécutant lui, et iui seul, que son résultat est différent. Lui, il ne se charge que de
où _arguments[1] (et [0]) sont écrits manuellement dans l'invite de commande aussi bien que dans le fichier batch.
Tout cela se résume donc à :
invite de commande
_encrypt.doFinal("Aïe, aïe, ça écrit pô bien !".getBytes()) //--> GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA=fichier batch
_encrypt.doFinal("Aïe, aïe, ça écrit pô bien !".getBytes()) //--> 5JaO3P+T0ZAEv4+Xbc/bbGvykgT1R0zO7vquGvHF150=Sans passer par un autre programme (ni aucune des deux autres classes, qui sont aussi des programmes indépendants et qui pourraient aussi bien ne pas exister pour l'affaire qui nous occupe) avant, pendant ou après.
Et comme je l'ai mentionné, avoir écrit le batch dans le bloc note Windows, fait "Enregistrer sous...", l'avoir appelé "ansi.bat" et avoir choisir ANSI comme encodage avant de valider et de fermer le bloc note a donné très exactement le même résultat (erroné) qu'avoir ensuite écrit le même batch dans le bloc note Windows, fait "Enregistrer sous...", l'avoir appelé "utf8.bat" et avoir choisir UTF-8 comme encodage avant de valider et de fermer.
Je te remercie chaleureusement en tout cas de m'aider à creuser tout ça, mais snif, et même ouin, pour ne pas dire grrr, je ne comprend toujours pas...
24 avril 2020 à 20:33
Quand je parlais de l'autre sens j'en étais au déchiffrement, c'est à dire à un problème de cohérence entre la conversion String →byte[] (Encrypt) et byte[] → String (Decrypt).
Mais il y a peut être un autre problème avant (ce qui n'empêche pas qu'il faudra traiter celui-ci quand même...)
Ci dessous, le même programme Encrypt (normalement), mais en décomposant pas à pas les opérations.
Exécutes le des deux côtés (batch et ligne de commandes) pour voir à quel moment il y a une différence.
Tu peux me copier-coller les résultats si tu ne trouves pas le problème par toi même.
import java.nio.charset.Charset; import java.util.Arrays; import java.util.Base64; import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; public class Encrypt { public static void main(String _arguments[]) throws Exception { System.out.println("charset\t" + Charset.defaultCharset()); System.out.println("key (base64)\t" + _arguments[0]); byte[] key = Base64.getUrlDecoder().decode(_arguments[0]); System.out.println("key (bytes)\t" + Arrays.toString(key)); Cipher _encrypt = Cipher.getInstance("AES"); _encrypt.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES")); System.out.println("input (String)\t" + _arguments[1]); byte[] input = _arguments[1].getBytes(); System.out.println("input (bytes)\t" + Arrays.toString(input)); byte[] output = _encrypt.doFinal(input); System.out.println("output (bytes)\t" + Arrays.toString(output)); System.out.println("output (base64)\t" + Base64.getEncoder().encodeToString(output)); System.out.println(); System.getProperties().forEach((k, v) -> System.out.println(k + "\t" + v)); } }Modifié le 24 avril 2020 à 23:00
Voilà celle en utilisant un batch encodé en ANSI
Et enfin celle en utilisant un batch encodé en UTF-8 (contrairement à ce que je disais le résultat n'est pas le même, mais c'est quand même une erreur et je ne peux l'enregistrer que dans l'un ou l'autre)
De ce que je vois, les encodages sont les mêmes via l'invite de commande et via les batch, pourtant l'output est différent... à cause de l'input, mais dans ce cas, pourquoi, comment peut-il lire la clé sans erreur dans le même input ?