This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm not an expert about security, but I found me maintaning a code which basically uses strong security and relies on BouncyCastle as provider. Code encrypts using DESede (3DES in EDE Mode), sends over FTP and receives trying to decrypt without success. the client making the encryption process lives at one Sun JVM 1.6, while server which decrypts is using an IBM JVM 1.6. No other JVM (No JVM provided by Sun) is suitable for this server cause its hardware architecture.
Key is generated and then used for encryption, later send encrypted with RSA algorythm to the server, which receives the key and tries to decrypt another file also sent to the server, which was encrypted using that key. When send unencrypted, key do decryption with success, when key is sent encrypted and later decrypted, code fails by throwing an exception: "javax.crypto.BadPaddingException: pad block corrupted.". Key with using RSA algorythm seems to be succesfully decrypted, but fails for decryption when used.
There are two paths I'm following for achieve my goal:
Scenario 1: Key is randomly generated, later encrypted using RSA encryption, written to a file, sent over the network, read, unencrypted succesfully, and later used for decrypt another file. -- Result: Fail
Scenario 2: Key is randomly generated, written to a file, sent over the network, read, and later used for decrypt another file -- Result: Success
Key is randomly generated:
Code for file encryption is almost the same used for file decryption:
I'm curious about this next and possibly it may affect the final result: There is a little difference between when it writes and when it reads the file encrypted with the key, about the buffer used. When encrypting, buffer is 1024, when decrypting, is 1032. Using 1024 when decrypting in Scenario 2 gives a fail, but when using 1032 in Scenario 2 it success decrypting the file (Remember Scenario 1 buffer is 1032 but throws a "BadPaddingException: Pad block corrupted" cause the key is sent encrypted and later decrypted):
A few questions about:
a) Considering the padding affects the result: How do I force to use a predefined padding for DESede in both sides, and what's the best padding strategy to be used for?.
b) May it be possible the key to become corrupted when encrypted and why (key is succesfully decrypted, so I would expect it should work decrypting the file)?
c) Why a 1032 bytes buffer does the work when decryption in Scenario 2?
d) What another issues I have to care for to get success in Scenario 1?
Any help should be appreciated. Thanks in advance.
If your are encrypting in parts you need to use the Cipher.update() method until the last part. Only for the last part, you use the doFinal() method. Same for decrypting. You should always give the specify the full "algorithm/mode/padding" transformation when calling Cipher.getInstance(). If you want things to work across different platforms and even JVMs do not rely on defaults for *anything*.
Nice to meet you.
Hugo Alberto Bedolla
Joined: Nov 09, 2010
greg stark wrote:If your are encrypting in parts you need to use the Cipher.update() method until the last part. Only for the last part, you use the doFinal() method. Same for decrypting. You should always give the specify the full "algorithm/mode/padding" transformation when calling Cipher.getInstance(). If you want things to work across different platforms and even JVMs do not rely on defaults for *anything*.
Hi... I got a solution; basically the problem was the key become corrupted when decrypted; altough the bytes looked the same in both sides, an undetermined issue respect the key byte ordering was affecting the decryption. I followed your recomendations by reimplementing the code using update() and the full transformation, anyway, the problem were arising yet; finally reached the solution when the bytes were serialized, later sent, and deserialized, so the bytes become in the exact order in both sides.