0

First I created a little encryption/decryption program in Java/Android. Nothing special about this just really basic, so no buffers or anything. Used an Iv and Salt there I write the salt and the iv at the beginning of the file(24 bytes) . This first version was able to en/decrypt a file and both files where binary the same in the end.

Now I tried to not read and process the whole file at once, but in single steps with a buffer (size 1024 bytes). I changed my cipher.doFinal to multiple cipher.update and one empty cipher.doFinal at the end.

Encryption:

byte[] salt = {1, 2, 3, 4, 5, 6, 7, 8};
byte[] iv = {23, 45, 23, 12 , 39, 111, 90, 1, 2, 3, 4, 5, 6, 7, 8, 9};

FileInputStream fis = new FileInputStream(f);
byte[] buffer = new byte[1024];

byte[] output = new byte[24];
cpyArray(iv, output, 0);
cpyArray(salt, output, 16);

FileOutputStream fos = new FileOutputStream(new File(f.getPath() + ".enc"));
fos.write(output);


Cipher cipher = getcCipher(pass, salt,iv, Cipher.ENCRYPT_MODE);

for(int length; (length = fis.read(buffer)) > 0; ) { 
    byte[] realbuffer = new byte[length];
    if (length != 1024) {
        cpyArrayUntil(buffer, realbuffer, 0, length);
    } else {
        realbuffer = buffer;
    }
    byte[] chipped = cipher.update(realbuffer)
    fos.write(chipped);
    System.out.println("Chipped: " + chipped.length);
}
cipher.doFinal();
fis.close();
fos.close();

Decryption:

 Cipher cipher = getcCipher(pass, salt, iv, Cipher.DECRYPT_MODE);
byte[] buffer = new byte[1024];
for(int length; (length = fis.read(buffer)) > 0; ) {
    byte[] realbuffer = new byte[length];
    if (length != 1024) {
        cpyArrayUntil(buffer, realbuffer, 0, length);
    } else {
        realbuffer = buffer;
    }
    byte[] chipped = cipher.update(realbuffer)
    fos.write(chipped);
    System.out.println("Chipped: " + chipped.length);
}
cipher.doFinal();

So, the problem is now, when I run this and compare the files at the end,
1. I get a BadPaddingExeption on the doFinal while decrypting. and
2. The file that was En-and Decrypted is missing 29 bytes at the end of the file.

No worries, the Iv and the salt are normally random, just static for testing.

Also, the missing bytes depend on the filesize. Just tryed another file and it is missing 21 bytes.

Julian
  • 3
  • 2
  • Check file Formats UTF-8 ANSI ... its could be the missing 29 bytes.. try writing /reading the file with the same File Format – Itzik Samara Aug 11 '15 at 17:28
  • Despite the 29 bytes missing, does the file otherwise match the expected file? Are the bytes that are written previously correct? – Artjom B. Aug 11 '15 at 17:29
  • 1. All bytes are exactly the same, just 29 missing at the end of the decrypted file. 2. Formats like UTF-8 should not matter, i am not convertig the bytes to strings or something and i am comparing them bytewise with a hex-Editor. – Julian Aug 11 '15 at 17:53
  • `CipherOutputStream` and `CipherInputStream` would clean up your code and eliminate some potential for bugs in your crazy buffer management. Edit your question to reflect the current situation. Did you change your code so that you are writing the result of `doFinal()` now when encrypting? Then your post should show that code and clearly describe the error you are currently getting. Comments aren't as clear as edits. – erickson Aug 11 '15 at 18:18

1 Answers1

0

You are discarding the output of doFinal() in both your encrypt and decrypt routines. These both return a byte[] which must also be written to your output in order for the encrypted ciphertext or decrypted plaintext to be complete and valid.

Iridium
  • 23,323
  • 6
  • 52
  • 74
  • Yea probably true, but i have a problem there: When decrypting, the doFinal throws an BadPadding Exeption, even with the correct key and everything. Now, if it throws the exeption, it does not return anything, it jumps into the catch block. – Julian Aug 11 '15 at 18:05
  • Ok, this seems to solve both problems in one go, thank you. I now write the bytes returned by both finals into the files too and it seems to work fine. Sadly no time to test it fully at the moment. – Julian Aug 11 '15 at 18:46
  • @Julian How did you solve the BadPaddingException? It seems that you haven't shared the full code. – Artjom B. Aug 11 '15 at 20:30
  • @ArtjomB. It seems very likely that the data lost as a result of dropping the result of `doFinal()` during encryption was the cause of the failure to decrypt with a `BadPaddingException`, thus fixing the encryption process simultaneously resolved the issues with decryption (hence "this seems to solve both problems in one go"). – Iridium Aug 11 '15 at 21:14