Problème de lecture/écriture d'un fichier chiffré

Version imprimable

Voir 40 message(s) de cette discussion en une page

14/03/2013, 12h23
Stud10

Problème de lecture/écriture d'un fichier chiffré

Bonjour,

Je fais un projet dans lequel un serveur chiffre un fichier A et écrit le résultat dans un autre fichier B (on concatène le cipher text, le vecteur d'initialisation et la clé à l'aide de l'opérateur +). Dans une seconde partie, un client doit récupérer les informations dans le fichier chiffré A afin de pouvoir utiliser son contenu.

Le problème est que le client ne récupère pas le texte sous la même forme que dans le fichier B (j'affiche ce qu'il récupère dans un terminal). Le string du fichier n'est pas sur une seule ligne (présence de retour chariot). Le problème apparaît seulement lorsqu'il y a plusieurs retour chariot dans le fichier (quand le string n'est pas sur une seule ligne).

Je ne possède pas de très grandes connaissances en Java mais je pense que le problème vient de l'encodage, ou de la lecture/écriture dans le fichier. A moins qu'il y ait une solution pour que le string soit tout le temps sur une seule ligne (pas de retour chariot).

Auriez-vous quelques idées sur ce problème?

Merci
14/03/2013, 13h36
hwoarang

Attention, si tu affiches ce que tu recois dans un terminal, il est possible que ce soit l'encodage du terminal qui pose probleme. Pour verifier que ce que tu envoies est la meme chose que ce que tu recois, il serait préférable de verifier au debugger.
Ceci étant dit, puisque tu fais du cryptage, le mieux est de ne pas passer par des String mais plutot par des byte[]. Comme ca, tu t'affranchiras des problèmes d'encodage et de caracteres indéfinis...
14/03/2013, 13h59
Stud10

Citation:

Envoyé par hwoarang

Attention, si tu affiches ce que tu recois dans un terminal, il est possible que ce soit l'encodage du terminal qui pose probleme. Pour verifier que ce que tu envoies est la meme chose que ce que tu recois, il serait préférable de verifier au debugger.
Ceci étant dit, puisque tu fais du cryptage, le mieux est de ne pas passer par des String mais plutot par des byte[]. Comme ca, tu t'affranchiras des problèmes d'encodage et de caracteres indéfinis...

J'affiche dans un terminal du serveur ce qu'il va copier dans le fichier et j'affiche dans le terminal du client ce qu'il lit, les deux résultats sont différents donc un problème d'encodage du terminal serait quand même possible ?

Et si je travaille en byte, comment je peux concaténer différents éléments à la suite sachant que j'utilise un délimiteur pour repérer les différents éléments à sélectionner.
15/03/2013, 09h57
hwoarang

Citation:

Envoyé par Stud10

J'affiche dans un terminal du serveur ce qu'il va copier dans le fichier et j'affiche dans le terminal du client ce qu'il lit, les deux résultats sont différents donc un problème d'encodage du terminal serait quand même possible ?

Oui, ca peut etre différent. Ca dépend de la configuration du terminal.

Citation:

Envoyé par Stud10

Et si je travaille en byte, comment je peux concaténer différents éléments à la suite sachant que j'utilise un délimiteur pour repérer les différents éléments à sélectionner.

Bah de la meme maniere que si c'est un String : en utilisant des caracteres de séparation spéciaux et en parcourant le tableau jusqu'à les retrouver. Le problème du cryptage, c'est que ca donne souvent des caracteres non-imprimables et qu'en fonction de l'encodage du String, ca peut faire des trucs bizarres.

Mais bon, pour etre plus précis, il faudrait que tu postes un bout de code...

Alors voici ma méthode pour générer une clé AES (à partir d'un mot de passe) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	private static SecretKey aesKey(char[] pwd) throws Exception{
		char[] password = pwd;
		byte[] salt = {
		        (byte)0xc7, (byte)0x73, (byte)0x21, (byte)0x8c,
		        (byte)0x7e, (byte)0xc8, (byte)0xee, (byte)0x99
		};
 
		SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
		KeySpec spec = new PBEKeySpec(password, salt, 65536, 128);
		SecretKey tmp = factory.generateSecret(spec);
		SecretKey aesKey = new SecretKeySpec(tmp.getEncoded(), "AES");
		return aesKey;
	}

Ma méthode pour chiffrer mon fichier :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
	private static String encryptAES(SecretKey key, String fileContent, String IV ) throws Exception {
		SecretKey aesKey = key;
		String plaintext = fileContent;
		byte[] iv = IV.getBytes();
		AlgorithmParameterSpec paramSpec = new IvParameterSpec(iv); 
		Cipher aesCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
		aesCipher.init(Cipher.ENCRYPT_MODE, aesKey, paramSpec);
	    byte[] ciphertext = aesCipher.doFinal(plaintext.getBytes());
	    String output = new String(ciphertext);
	    return output;
	}

Veux tu voir d'autres bouts de code ?

17/03/2013, 15h50
tchize_

Tu utilise bien InputStream / OutputStream et non pas les Reader/writer pour gérer ton fichier?
17/03/2013, 16h48
Stud10

Non j'utilise des FileWriter et FileReader (avec des BufferReader) le problème pourrait venir de la ?
17/03/2013, 17h06
tchize_

Plutot oui, avec ça tu lit du texte, alors que, a priori, une clé crypto et un fichier crypté, c'st du binaire, pas du texte, beaucoup de séquences de bytes ne sont pas représentables sour forme de charactères.
17/03/2013, 18h47
Stud10

Mais je vais pouvoir continuer à travailler avec mon string de la forme :
Cipher || vecteur initialisation || hash ?
17/03/2013, 18h56
tchize_

Non, parce que ça

String output = new String(ciphertext);

ça ne peux pas marcher correctement. Qu'est-ce que tu fais si t'as le byte 0 dans ton array? Ce n'est pas représentable. En plus tu es du coup dépendant de l'encodage par défaut de la plateforme où tu tourne, ce qui ne fait qu'empirer les chose. Si tu veux convertir ton byte[] en chaine de caractère, il faudra passer par des conversion. Soit tu l'affiche en hexadecimal, soit tu passe par des encodage comme le BASE64.
18/03/2013, 09h37
hwoarang
Citation:
Envoyé par Stud10

Code:

1 2 byte[] ciphertext = aesCipher.doFinal(plaintext.getBytes()); String output = new String(ciphertext);
Tu remarqueras que ta fonction de cryptage renvoie un byte[] et non un String. Ce n'est pas un hasard et ca rejoins ce que j'ai dit plus tot. Certains caracteres peuvent etre non imprimables et ne pas passer dans le String (ce qui semble etre le cas qui te pose probleme).
Maintenant, il y a 2 possibilitées :
- Soit tu peux envoyer le byte[] plutot que le String et le déchiffrer de l'autre coté (c'est le mieux)
- Soit tu es obligé de passer un String et à ce moment la, il va falloir faire l'encodage dans les 2 sens (byte[] -> String puis String -> byte[]).
18/03/2013, 14h03
Stud10

Quelle serait alors la meilleure solution pour pouvoir écrire ceci dans le fichier : cipher || iv || hash, sachant que je dois facilement pouvoir les séparer quand je lis le texte avec mon client ?
18/03/2013, 14h20
thelvin

Bonjour,

En général on encode le binaire en hexadécimal ou en base64.

Ça te permet d'utiliser comme séparateur, n'importe quel caractère qui n'apparaît pas en hexadécimal (ou en base64.) C'est notamment le cas de | ou de ;
18/03/2013, 14h21
Stud10

J'avais essayé d'encoder en base64 mais je n'ai pas réussi à trouver la librairie à importer pour que les methodes soient reconnues..
18/03/2013, 14h29
thelvin

Il en existe une tétrachiée, mais je recommande toujours Apache commons-codec.
18/03/2013, 21h00
Stud10

J'avais déjà essayé cette librairie en écrivant ceci :
import org.apache.commons.codec.binary.Base64;

, mais quand je compile j'ai une erreur comme quoi la librairie n'existe pas.

Le problème est que mon programme va être compilé et exécuté sur une machine de l'université, donc si je dois installé la librairie pour que ça marche j'ai peur que cela bloque lors de l'évaluation de mon projet en fait..
18/03/2013, 22h54
tchize_
ben si tu veux pas t'emmerder -> tu oublie les ficheir texte, et tu stocke du binaire directement dans tes fichiers (je vois pas pourquoi ça devrait être du texte).

Sinon, compiler avec des librairies additionnelles, c'est pas bien compliqué:
Code:

1 2 javac -cp laLibrairie.jar ton/Main.java java -cp laLibrairie.jar:. ton.Main
Il n'est pas question "d'installer" ;)
18/03/2013, 23h01
Stud10
Citation:
Envoyé par tchize_

ben si tu veux pas t'emmerder -> tu oublie les ficheir texte, et tu stocke du binaire directement dans tes fichiers (je vois pas pourquoi ça devrait être du texte).

Sinon, compiler avec des librairies additionnelles, c'est pas bien compliqué:

Code:

1 2 javac -cp laLibrairie.jar ton/Main.java java -cp laLibrairie.jar:. ton.Main

Il n'est pas question "d'installer" ;)
Et si je stocke du binaire, je peux concaténer différents byte et les séparer avec un caractère spécial afin de pouvoir séparer mes différents éléments quand je lirais mon texte ?
18/03/2013, 23h53
thelvin

Ma foi non, en effet, ou du moins pas facilement, puisque le byte séparateur peut toujours apparaître en plein milieu des données.
Mais bon, ce qu'on fait à la place, en binaire, c'est d'abord on indique la taille des données, puis on met les données. La séparation est implicite, c'est juste quand on a atteint la taille annoncée.

Personnellement j'ai encore un autre avis, dans le cas où on peut vraiment pas utiliser de bibliothèque (ce n'est pas une histoire d'installer, mais bon, des fois on a pas droit aux bibliothèques) : pourquoi pas le faire soi-même ? Pour la base64 on va dire que c'est compliqué. Mais en hexadécimal, et depuis String.format()... C'est juste une boucle, c'est pas tuant non plus.
19/03/2013, 00h01
Stud10

Citation:

Envoyé par thelvin

Ma foi non, en effet, ou du moins pas facilement, puisque le byte séparateur peut toujours apparaître en plein milieu des données.
Mais bon, ce qu'on fait à la place, en binaire, c'est d'abord on indique la taille des données, puis on met les données. La séparation est implicite, c'est juste quand on a atteint la taille annoncée.

Personnellement j'ai encore un autre avis, dans le cas où on peut vraiment pas utiliser de bibliothèque (ce n'est pas une histoire d'installer, mais bon, des fois on a pas droit aux bibliothèques) : pourquoi pas le faire soi-même ? Pour la base64 on va dire que c'est compliqué. Mais en hexadécimal, et depuis String.format()... C'est juste une boucle, c'est pas tuant non plus.

On utilise un makefile imposé pour compiler notre programme donc pour la librairie ça va pas être possible..
Comme je l'ai dis plus haut, j'ai très peu de connaissances en Java et je cherche juste le moyen le plus simple pour arriver à écrire mon fichier comme ceci cipher || iv || hash, et pouvoir à la lecture du texte dissocier ces éléments

Voir 40 message(s) de cette discussion en une page