aspose file tools*
The moose likes Other JSE/JEE APIs and the fly likes Java cipher keys convertion does not properly work Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Other JSE/JEE APIs
Bookmark "Java cipher keys convertion does not properly work" Watch "Java cipher keys convertion does not properly work" New topic
Author

Java cipher keys convertion does not properly work

coppermein pezdosos
Greenhorn

Joined: Jan 15, 2013
Posts: 2
I have the code:

In the last statement I cause the failure: "Inappropriate key specification". That failure caused also I using in the last statement SKC instead of PKS. Code example I using I give from the Internet. Please kick me to the my mistake. In all examples, but statement does work at all:

Can be help me? PLEASE!!!
Richard Tookey
Ranch Hand

Joined: Aug 27, 2012
Posts: 1110
    
  10

There seems to be a bug in SecretKeyFactory for the SunJCE provider and it seems to go back to at least JDK1.6. Using your code using BouncyCastle provider works! At some point I shall research this bug but I don't have time at the moment.

Fortunately since SecretKeySpec extends SecretKey there is a very simple work round. Just use -


Notes -

1) Your exception handling is some of the worst I have ever seen. One cannot just ignore exceptions like that. Any exception in that code is absolutely fatal since the whole encryption code fails but in your code without anyone being any the wiser!

2) DES is no longer considered secure and AES is preferred.

3) In the JCE DES expects the key to be exactly 8 bytes with the least significant bit of each byte being an odd parity bit. You can get away with not setting the parity. AES expects the key to be either 16, 24 or 32 bytes exactly.

4) You have created a PBEKeySpec but nothing in your key generation uses it! Any reason? If you are going to use a password to define a key then you should probably be using some form of PBE and not just using the raw bytes of the password as a key.

5) Please try to use the Java coding conventions. From the point of view of the forum members and other Java developers it makes your code much more readable.
coppermein pezdosos
Greenhorn

Joined: Jan 15, 2013
Posts: 2
Richard Tookey wrote:There seems to be a bug in SecretKeyFactory for the SunJCE provider and it seems to go back to at least JDK1.6. Using your code using BouncyCastle provider works! At some point I shall research this bug but I don't have time at the moment.
I do not want to use external, non-standard libraries for more compatibility.
Richard Tookey wrote:Fortunately since SecretKeySpec extends SecretKey there is a very simple work round. Just use -
Sorry, but code:always give me error: "Inappropriate key specification". What is wrong?
Richard Tookey wrote:Notes -
1) Your exception handling is some of the worst I have ever seen. One cannot just ignore exceptions like that. Any exception in that code is absolutely fatal since the whole encryption code fails but in your code without anyone being any the wiser!
My listed in my post code only in the test case code - it not real work code!
Richard Tookey wrote:2) DES is no longer considered secure and AES is preferred.
Yes, I know this. But Java SunJCE support in the default 128-bit AES; 256-bit AES encryption only supports as perversion. So, DES is my favorite algorithm, and so, 56-bit encryption enough for most instances for encryption texts - more bit encryption want only the FBI/CIA staffs and criminal persons.
Richard Tookey wrote:3) In the JCE DES expects the key to be exactly 8 bytes with the least significant bit of each byte being an odd parity bit. You can get away with not setting the parity. AES expects the key to be either 16, 24 or 32 bytes exactly.
I need to make encryption/decryption methods uses the user random length passwords. I use PBEKeySpecs with salt (
Richard Tookey wrote:4) You have created a PBEKeySpec but nothing in your key generation uses it! Any reason? If you are going to use a password to define a key then you should probably be using some form of PBE and not just using the raw bytes of the password as a key.
This code only is test case. But not real.
Richard Tookey wrote:5) Please try to use the Java coding conventions. From the point of view of the forum members and other Java developers it makes your code much more readable.
Sorry, but I have my own conventions for coding, have it from the old school of C/C++.
Richard Tookey
Ranch Hand

Joined: Aug 27, 2012
Posts: 1110
    
  10

coppermein pezdosos wrote:
Richard Tookey wrote:There seems to be a bug in SecretKeyFactory for the SunJCE provider and it seems to go back to at least JDK1.6. Using your code using BouncyCastle provider works! At some point I shall research this bug but I don't have time at the moment.
I do not want to use external, non-standard libraries for more compatibility.

I was not suggesting the use of thirt party libraries! I was just illustrating that there was a bug in the SunJCE provider.

Richard Tookey wrote:Fortunately since SecretKeySpec extends SecretKey there is a very simple work round. Just use -
Sorry, but code:always give me error: "Inappropriate key specification". What is wrong?


I told you - there seems to be a bug in the JCE! The single line of code


is all you need! You don't need to create a key factory!


Richard Tookey wrote:Notes -
1) Your exception handling is some of the worst I have ever seen. One cannot just ignore exceptions like that. Any exception in that code is absolutely fatal since the whole encryption code fails but in your code without anyone being any the wiser!
My listed in my post code only in the test case code - it not real work code!

Then why include the exception handling in the first place? It detracts from the clarity of the code and is not needed!


Richard Tookey wrote:2) DES is no longer considered secure and AES is preferred.
Yes, I know this. But Java SunJCE support in the default 128-bit AES; 256-bit AES encryption only supports as perversion.

The JunJCE provider has 100% supported AES for a long time (I think since JDK1.5). I don't understand at all you use of 'perversion' in this context; 256 bit keys have been supported since AES was first introduced into the SunJCE provider! There is nothing perverse about this!

So, DES is my favorite algorithm, and so, 56-bit encryption enough for most instances for encryption texts - more bit encryption want only the FBI/CIA staffs and criminal persons.
Richard Tookey wrote:3) In the JCE DES expects the key to be exactly 8 bytes with the least significant bit of each byte being an odd parity bit. You can get away with not setting the parity. AES expects the key to be either 16, 24 or 32 bytes exactly.
I need to make encryption/decryption methods uses the user random length passwords. I use PBEKeySpecs with salt (

But your code is not using that! The originally cod you posted had a PBESpec (which you did not actually use) which could be used with just one more line of code to avoid all the rest of the code!

Richard Tookey wrote:4) You have created a PBEKeySpec but nothing in your key generation uses it! Any reason? If you are going to use a password to define a key then you should probably be using some form of PBE and not just using the raw bytes of the password as a key.
This code only is test case. But not real.
Richard Tookey wrote:5) Please try to use the Java coding conventions. From the point of view of the forum members and other Java developers it makes your code much more readable.
Sorry, but I have my own conventions for coding, have it from the old school of C/C++.


But the code you posted that throws the exception does not use PBE! It uses the raw bytes of a String as the bytes of the key so for DES needs to be exactly 8 bytes!

I have read your response several time and I really can''t see what makes DES your favourite algorithm.

Since you seem to ignore my suggestion about getting round the JCE I don't think I can help any further.

Bye





 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java cipher keys convertion does not properly work