question about DES API

[jim]

Hello All,

The following is the code I wrote to do DES encryption.
public byte[] run ()throws Exception
{
// TODO Auto-generated method stub
byte[] re = null;
byte[]re1 = null;
if (key.length != 8){
throw new DesException("Invalid Key!!!");
}
KeyGenerator kg = KeyGenerator.getInstance("DES");
SecretKey sk = kg.generateKey();
SecretKeySpec desKey = new SecretKeySpec(key, "DES");
Cipher des = Cipher.getInstance("DES");
if ((comm == Cipher.DECRYPT_MODE) && (data.length != 8)){
throw new DesException("Invalid Key!!!");
}
des.init(Cipher.ENCRYPT_MODE, desKey);
int l = des.getOutputSize(8);
re = des.doFinal(data);

des.init(Cipher.DECRYPT_MODE, desKey);
l = des.getOutputSize(16);
re1 = des.doFinal(re);
return re;
}

I don't understand why I try entrypt 8 bytes data, the the length of
return value is 16 bytes, the first 8 bytes are what I want, what are
last 8 bytes? as far as I know, for des, the input block is 8 bytes,
output block is 8 bytes too. I use this return value to decrypt, I got
correct value.

If I just input first 8bytes to decrypt I got exception.

Anyone can explain this to me or recommend any detail document about
these API?


Thanks a lot.

 

[jan V]

The following is the code I wrote to do DES encryption.

Given that you're not stating what your problem is before pasting your code,
I'm switching to neutral, i.e. code reviewer mode ;-)

public byte[] run ()throws Exception

run() ought really to be reserved for thread-related logic. If your method
isn't run as a separate thread, maybe another, more descriptive name would
be better.

Also, adding a "throws Exception" is a very problematic technique. Other
threads in this NG have talked about this at length..

byte[] re = null;
byte[]re1 = null;

These identifiers are likewise very poor quality.

if (key.length != 8){
throw new DesException("Invalid Key!!!");
}

No, the error message to the user should say "Invalid key length: " +
key.length

KeyGenerator kg = KeyGenerator.getInstance("DES");

desKeyGenerator would be a much better name. kg sucks big time, like most
two letter identifiers

SecretKey sk = kg.generateKey();

secretKey would be much better

SecretKeySpec desKey = new SecretKeySpec(key, "DES");
Cipher des = Cipher.getInstance("DES");

desCipher would be much better

if ((comm == Cipher.DECRYPT_MODE) && (data.length != 8)){

This is the second time you're using the magic constant 8. Once is bad
enough, but twice really is the trigger to use a symbolic constant instead..

throw new DesException("Invalid Key!!!");

Another one of those really unhelpful error messages. Think of your users...
put yourself in their shoes. "Invalid Key!!!" sucks as a message. It's the
kind of error message which drives users up the walls.

}
des.init(Cipher.ENCRYPT_MODE, desKey);
int l = des.getOutputSize(8);

Please, tell me you didn't use lowercase L as an identifier !!!! <slaps
head>

re = des.doFinal(data);

Does "re" stand for result or something? Why force readers of your code to
guess? Choose identifiers that leave no room for guess work....

I don't understand why I try entrypt 8 bytes data, the the length of
return value is 16 bytes, the first 8 bytes are what I want, what are
last 8 bytes? as far as I know, for des, the input block is 8 bytes,
output block is 8 bytes too. I use this return value to decrypt, I got
correct value.

See how not understanding things isn't very nice? Likewise with code
readability...

Anyone can explain this to me or recommend any detail document about these

API?

Have you checked the DES snippets in the Java Almanac?
http://javaalmanac.com/egs/javax.crypto/pkg.html

 

[jim]

Thanks a lot for your comments

 

[Raymond DeCampo]

jan V wrote:
[Attribution missing from jan's post]

No, the error message to the user should say "Invalid key length: " +
key.length

May I suggest something along the lines of "Only keys with 8 bytes are
valid," instead; then the user does not have to guess what the magic key
length is to make the method work.

Ray

 

[Roedy Green]

byte[] re = null;
byte[]re1 = null;

These identifiers are likewise very poor quality.

For hints on naming see

http://mindprod.com/jgloss/

 

[Roedy Green]

byte[] re = null;
byte[]re1 = null;

These identifiers are likewise very poor quality.

for hints on naming see my essay on how to write unmaintainable code
at http://mindprod.coml/jgloss/unmainnaming.html

and my essay on choosing good names at
http://mindprod.com/jgloss/naming.html

 

[Roedy Green]

I don't understand why I try entrypt 8 bytes data, the the length of
return value is 16 bytes, the first 8 bytes are what I want, what are
last 8 bytes? as far as I know, for des, the input block is 8 bytes,
output block is 8 bytes too. I use this return value to decrypt, I got
correct value.

In general encrypted data is fatter than the plain text.

For short strings more so, since often there is random padding called
salting thrown in on the front so that the same message encrypted
twice won't be encrypted the same way.

Imagine a credit card being sent encrypted. Without salting, the CIA
might not know the credit card number, but they could tell the same
person made yet another purchase from Terrist Supplies 'R Us.

And this is without ANY code cracking.

 

[Roedy Green]

Anyone can explain this to me or recommend any detail document about
these API?

See Knudsen's book. Link at
http://mindprod.com/jgloss/cryptography.html

 

[jan V]

jan V wrote:
[Attribution missing from jan's post]

No, the error message to the user should say "Invalid key length: " +
key.length

May I suggest something along the lines of "Only keys with 8 bytes are
valid," instead; then the user does not have to guess what the magic key
length is to make the method work.

Good suggestion. And I'd like to improve on that by including the explicit
cause of the problem:

"Only 8-byte keys are valid, this key is " + key.length + " bytes long."

When I get error messages, I really like to get more than just a static
string. Very often, as in this example, adding some "hot off the presses"
data makes the error message more informative, more current, more "Ah, of
course." for the user. As we all experience all the time, programmers don't
spend much effort on creating truly user-friendly messages, and that's a big
shame.