Java encryption

[JavaEnquirer]

I'm reading textual data out of an SQL Server 2005 database. This works

fine as you'd expect, however, when I attempt to decrypt encrypted
String data
read out of the database using the Java cryptography classes I get the
following error:

javax.crypto.IllegalBlockSizeException: Input length must be multiple
of 8 when decrypting with padded cipher

When I manipulate the Strings locally, encrypting and decrypting them
back, everything is fine. The seems to be some hidded problem with the
Strings extracted from the database.

Any one got any ideas? One theory I have concerns the fact that SQL
Server 2005 uses USC-2 encoding whereas the decrypter expects UTF-8.
Could this be at the heart of the problem? If so, how would I go about
converting a USC-2 String into a UTF-8 encoded String?

 

[Chris Uppal]

I'm reading textual data out of an SQL Server 2005 database. This works

fine as you'd expect, however, when I attempt to decrypt encrypted
String data
read out of the database using the Java cryptography classes I get the
following error:

Given that encrypting a string produces binary data, why are you storing it as
text in your database ?

And, given that apparently you /are/ doing so, why do you expect it to work ?
Arbitrary binary data will not conform to the rules of any character encoding
such as UTF-16 or UTF-8 and is likely to be mangled (if not rejected outright)
if treated as such. The only character encoding in which it might be safe to
pretend the binary data was "really" character-encoded text would be something
like ISO-8859-1 where each of 0..255 corresponds to exactly one character.

If you /must/ save binary data as text then it is almost certainly better to
re-encode it /as/ text, using something like base-64 encoding -- before saving
it.

-- chris

 

[JavaEnquirer]

Apologies for wasting bandwidth. This is actually a non problem. SQL
Server 2005 gives no problems what so ever with storing Java encrypted
Strings and allowing you to read them out an decrypt them. ( Assuming
you do eveything sensibly like using BASE64 encoding )
I fell into the classic mistake of over thinking the problem. My data
inputting stored procedure was using a varchar of a size too small and
was consequently truncating the encrypted string I was passing in,
hence causing the decryption to fail. Damd those typos.

 

[JavaEnquirer]

Given that encrypting a string produces binary data, why are you storing it as
text in your database ?

And, given that apparently you /are/ doing so, why do you expect it to work ?
Arbitrary binary data will not conform to the rules of any character encoding
such as UTF-16 or UTF-8 and is likely to be mangled (if not rejected outright)
if treated as such. The only character encoding in which it might be safe to
pretend the binary data was "really" character-encoded text would be something
like ISO-8859-1 where each of 0..255 corresponds to exactly one character.

If you /must/ save binary data as text then it is almost certainly better to
re-encode it /as/ text, using something like base-64 encoding -- before saving
it.

-- chris

Cheers, I ommited to mention that I was using BASE 64, something like:

byte[] utf8 = text.getBytes( encoding );

// Encrypt
byte[] enc = cipher.doFinal( utf8 );

// Encode bytes to base64 to get a string
encryptedString = new sun.misc.BASE64Encoder().encodeBuffer( enc );

 

[Chris Uppal]

My data
inputting stored procedure was using a varchar of a size too small and
was consequently truncating the encrypted string I was passing in,
hence causing the decryption to fail. Damd those typos.

Oh dear! You have my sympathy....

-- chris