1

When decrypting a String with com.googlecode.gwt.crypto.client.TripleDesCipher#decrypt the following exception is thrown:

java.lang.ArrayIndexOutOfBoundsException: -59 
at com.googlecode.gwt.crypto.bouncycastle.util.encoders.HexEncoder.decode(HexEncoder.java:106) 
at com.googlecode.gwt.crypto.bouncycastle.util.encoders.Hex.decode(Hex.java:86)
at com.googlecode.gwt.crypto.client.TripleDesCipher.decrypt(TripleDesCipher.java:51)

The String that is passed to the method contains a special character.

Has anyone of you encountered such an error before?


The String that is passed to the decrypt method contains the special character Ţ. It is encoded in UTF-8 but is somehow parsed by the TripleDesCipher as ISO-8859-1.

Harold L. Brown
  • 8,423
  • 11
  • 57
  • 109

2 Answers2

1

Java is using UTF-16 for its own encoding: most of the Character will be using 16 bits, but there are some exception. When a character can not be encoded in UTF-16, it will be encoded using hi-surrogate (1 char) and low-surrogate (1 char), so taking 2 native Java char space.

You char representation is:

Ţ : LATIN CAPITAL LETTER T WITH CEDILLA (U+0162) : feff0162

The java representation will be 2 java native char (0xfeff and 0x0162). You can detect this behaviour by testing if one character is a high surrogate (in this case it must be immediately followed by a low surrogate).

More info on javadoc:

http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isHighSurrogate%28char%29

and in general in Character header doc:

http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html

EDIT

Forget the previous response, it should not linked with data-representation. It seems that any string you want to "decrypt" must be encrypted as Hexadecimal first. So this excludes Ţ as being a potential value in the encrypted data. Your input should be already wrong before giving it to TripleDesCipher.decrypt method.

csauvanet
  • 534
  • 2
  • 15
  • Maybe I answered a bit fast, you character seems to be in the UTF-16 2-byte coded range: http://www.fileformat.info/info/unicode/char/0162/index.htm – csauvanet Mar 20 '15 at 09:58
0

As already mentioned in the answer the problem was that we read an UTF-8 String as it was ISO-8859-1 and passed it to the decrypt method.

The wrong encoding was due to a multipart/form-data request.

Harold L. Brown
  • 8,423
  • 11
  • 57
  • 109