• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java cipher keys convertion does not properly work

 
coppermein pezdosos
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1166
17
Java Linux Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1166
17
Java Linux Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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





 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic