aspose file tools*
The moose likes Security and the fly likes What broke between 1.4 and 1.6 for decryption? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "What broke between 1.4 and 1.6 for decryption?" Watch "What broke between 1.4 and 1.6 for decryption?" New topic
Author

What broke between 1.4 and 1.6 for decryption?

Wb Moore
Greenhorn

Joined: Sep 13, 2007
Posts: 9
This code works in Java 1.4.2, but it throws "javax.crypto.BadPaddingException: Given final block not properly padded" exception in Java 1.6.

What has changed?


When it tries to decrypt, it throws the exception at the c.doFinal for the decryption (ie. "decryptedbytes = c.doFinal(decodedbytes);").

As I have said, it works fine in Java 1.4.2, but fails in Java 1.6.

Any suggestions to what I am doing wrong?

Please dont suggest the need to move to 3DES. I am aware of the need. I am not able to do so at the moment. There are plans for moving to a stronger encryption scheme. But right now, I need to get this working.

thanks!
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220

is incorrect usage for two reasons. It 1) assumes the default SecureRandom algorithm will not change and 2) assumes that the supplied seed material is the only source of seed material. This is the likely source of your issues.

2. Using any functionality directly from sun.misc is a bug. Those classes are not for use by programmers. They can be removed at any time or may not even be present on other Java runtimes. And even if the functionality remains it might be renamed. Why shouldn't Oracle rename these class oracle.misc.*?

3. Never use the no-args versions of String.getBytes() and new String(...). The default charset is different on different platforms, so this is just asking for more bugs.

Nice to meet you.
Wb Moore
Greenhorn

Joined: Sep 13, 2007
Posts: 9
greg stark wrote:
is incorrect usage for two reasons. It 1) assumes the default SecureRandom algorithm will not change and 2) assumes that the supplied seed material is the only source of seed material. This is the likely source of your issues.

2. Using any functionality directly from sun.misc is a bug. Those classes are not for use by programmers. They can be removed at any time or may not even be present on other Java runtimes. And even if the functionality remains it might be renamed. Why shouldn't Oracle rename these class oracle.misc.*?

3. Never use the no-args versions of String.getBytes() and new String(...). The default charset is different on different platforms, so this is just asking for more bugs.


Yes, I noticed that SecureRandom call also (this is inherited code). After further testing determined that is the problem.
I expect to be able to replace this method in the future, but that would entail much more than simply getting this to work.

Thank you for your assitance.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What broke between 1.4 and 1.6 for decryption?