encryption/decryption & java - basic questions

Question

I have to implement the following scenario.

User calls a webservice sending a request with a text which must be encrypted by my service if it isn't encrypted. After that it should be stored in the database. Is it a good idea to declare this attribute in xsd as String or is it a better type? Should I allow to use CDATA?

Using Jaxb I will convert this xml to a class with password stored in String object. Is it ok assuming that String is unicode (2 bytes)?

I have to use API which is a wraper for RSA client with 2 methods:

• decryptInformation(String)
• encryptInformation(String)

In most cases encrypting methods take an array of bytes as a parameter... I'm wondering if it may cause any unexpected errors.

I've also seen that people use Base64 class to do the encoding and decoding. Should I use it before I store encrypted text in database? Could you please explain it to me in a simple way?

Answer 1

From what I understand, here is the sequence you should implement:

1. Send the server's public key to the client
2. Make the client sign the password (returns byte[])
3. Base64 encode the signed password (returns String)
4. Send the base64 string via your web-service (using xsd:base64Binary)
5. On the server, unmarshall (using JAXB) the password (returns the byte array)
6. Store a base64 encoded string, a hex string, or the byte array (in Lob).

Answer 2

Depending on your encryption method the encrypted string might contain random byte orders, including stuff that might confuse a XML parser - including stuff like ]]> that's unlikely but possible. Additionally the encrypted stirng might contain NULL bytes orother non-visible characters which create trouble while passing the file along.

Base 64 encoding makes sure only "valid" characters end in the document so you should base 64 encode your encrypted text.

Answer 3

On the need of encoding
With many encryption methods, the ciphertext, i.e. the encrypted form of a message is an array of bytes, i.e. if viewed as sequence of "characters" the ciphertext could include any character between 0 and 255 (decimal) or $00 and $FF (hexadecimal). Such a range of characters includes many non-printable characters, say "tab" or "eot", as well as characters with a code above 128, which interpretation may vary.
Furthermore, even discounting these non-printable or "non-ASCII" characters, some characters in the ciphertext may be such that they "throw off" the interpretation of a possible format where the ciphertext is included (as for example XML, as hinted in the question).

For this reason, ciphertext must often be encoded so that it can be printed or included in text-oriented containers.

All encoding (of binary to text-like format) result in using more space for the encoded form of the data. Base64 is a popular format because it is relatively compact.

Another possible encoding format is hexadecimal ("base 16") which takes twice the size as the original binary data. Hexadecimal is also simpler/easier to use since there is a direct mapping between any byte in the input and its two corresponding characters in the output. (whereby Base64 uses 1.25 characters to encode one byte, leading to blocks of 3 input bytes for encoded bytes)

On the need to "Escape" encoded data
Once the cyphertext is encoded, it may still include characters susceptible of throwing-off the structure of the "outside" format where the ciphertext is included, and that is why, in the case of XML, you may want to "escape" this content as CDATA. (This is not necessary with Hexadecimal, and may not be needed in Base64, depending on the two extra character used (Base64 uses 0 thru 9, A thru Z, a thru z and two extra characters, typically + and /, as well as =).

On the need of storing data in database as Base64 (or other encoding)
People use Base64 (or similar encodings) to store data in databases for two distinct reasons:

• to introduce a [mild/weak] encryption, for data which is readily in text form. It is a weak form of encryption, as someone may quickly identify the encoding. Never the less it makes the data stored less "obvious".
• to store data that is in binary form, as TEXT.

Most DBMSes include data types that allow stroring sequences of bytes in binary format, and it would therefore not be necessary to use encoding and storage to a Text-type format. However, there are many reasons why people may still choose to store as text:

• because the data is eventually handed-out/used as encoded text (no need encrypt at run time, just encrypt once when data is stored)
• to facilitate portability
• to make debugging easier