0

One of our clients will upload a ENCRYPTED file in our application and we will move that file to our AIX server and decrypt it. The file is not getting decrypted properly. If I manually move the encrypted file through SFTP to the AIX server, decryption works perfectly but not when then file is uploaded from Windows. The key is same for encryption by the client and decryption by us. This is not happening for all the encrypted files though, problem for few files and we dont find anything different in those files. We use Bouncy Castle for generating the key as well as for encryption and decryption.

Exception:

javax.crypto.IllegalBlockSizeException: last block incomplete in decryption
        at org.bouncycastle.jcajce.provider.symmetric.util.BaseBlockCipher.engineDoFinal(Unknown Source)
        at javax.crypto.Cipher.doFinal(Unknown Source)

Decrypt Code:

public void decryptFile(InputStream fis, OutputStream fos)
        throws IOException,
        ShortBufferException,
        IllegalBlockSizeException,
        BadPaddingException
{
   byte[] buffer = new byte[16];
   int noBytes = 0;
   byte[] cipherBlock =
           new byte[decryptCipher.getOutputSize(buffer.length)];
   int cipherBytes;
   while((noBytes = fis.read(buffer))!=-1)
   {
       cipherBytes =
               decryptCipher.update(buffer, 0, noBytes, cipherBlock);
       fos.write(cipherBlock, 0, cipherBytes);
   }
   cipherBytes = decryptCipher.doFinal(cipherBlock,0);
   fos.write(cipherBlock,0,cipherBytes);

   fos.close();
   fis.close();
}

How do we handle this?

saratbala
  • 29
  • 3
  • 1
    What file transfer mode are you using - Binary or ASCII ? – anacron Mar 14 '17 at 05:19
  • We are transferring the file using org.springframework.web.multipart.commons.CommonsMultipartFile.transferTo(File arg0) – saratbala Mar 14 '17 at 05:30
  • 1
    After you upload the file, can you perform a hash on both the source and destination to confirm if the file is getting changed during transfer ? For example, using `csum -h MD5 ` on AIX and `fciv -md5 ` on Windows. – anacron Mar 14 '17 at 05:54
  • You can get `fciv` from Microsoft's website here: https://support.microsoft.com/en-in/help/841290/availability-and-description-of-the-file-checksum-integrity-verifier-utility – anacron Mar 14 '17 at 05:59
  • The checksum value is same in both source and destination. There is no difference in that. – saratbala Mar 14 '17 at 06:12
  • Is your encrypted file Base64 encoded ? If so, are you decoding it before your decrypt? – anacron Mar 14 '17 at 06:19
  • The code here looks good to me. The transport code might be broken or even the encryption code. Both of which you haven't shared. Please add [Minimal, Complete and Verifyable example](/help/mcve). – Artjom B. Mar 14 '17 at 06:24
  • Hi anacron , We didnt encode the file. May be, I can try doing that. I will do that and update here... – saratbala Mar 14 '17 at 06:47
  • HI Artjom B., The encrypt and decrypt is same code.. Only change is the cipher mode will be ENCRYPT_MODE and DECRYPT_MODE respectively. File Transfer happens through CommonsMultipartFi‌​le.transferTo(File arg0). – saratbala Mar 14 '17 at 06:53
  • The error is random or always happen with the same file? In the first case, are you processing the file as it arrives?(may be a ciphered block is not completely received). In the second case it is an encoding issue – pedrofb Mar 14 '17 at 06:57
  • It always happens with same file. I cant come to a conclusion that it is an encoding issue - reason is I am able to decrypt the file properly if I move the file to server through SFTP instead of uploading from the application. – saratbala Mar 14 '17 at 07:06
  • Try to base64 encode before sending – pedrofb Mar 14 '17 at 07:15
  • Get the problematic file; perform the file-transfer both ways (java/commons and sftp); compare the transmitted files on the AIX-computer with `cmp(1)`. It the files are the same, then it is dark magic; if they aren't, then one of the two file-transfer methods is broken. – Lorinczy Zsigmond Mar 14 '17 at 09:49
  • When I compared the two file they arent same. The problem is one of the file is in DOS/Windows format and other one is in unix format. The file is DOS/Windows format is not getting decrypted properly due to EOL spaces. I am not able to use dos2unix command because the file is in encrypted format and it throws exception if I use that command. Any java util that can convert EOL spaces to UNIX format? – saratbala Mar 15 '17 at 04:59
  • As they are binary files, there is no DOS or Unix format. The problem lies in the file-uploading method: it isn't binary-safe. – Zsigmond Lőrinczy Mar 15 '17 at 05:53

0 Answers0