Thanks for a good introduction on how to encrypt small amounts of data. Your comment helped correct some of my confusion on the subject.

Thanks for a good introduction on how to encrypt small amounts of data. Your comment helped correct some of my confusion on the subject.

About short data types – yes, they could be easier to brute force, but only if we didn’t generate the encryption key with the enough strength. In PBE, if we follow the RSA standards (and jasypt does), for generating the encryption key, the password is added a (preferably random) salt, and then it is applied a hash function a number of times (iteration count).

The addition of a random salt, and the application of a hash function many times (RSA recommends at least 1,000) adds an important strength to the resulting encryption key (it is the same process as described in “Encrypting Passwords” in the jasypt website http://www.jasypt.org/encrypting-passwords.html), and, among other desirable effects, allow the domain of the result of the encryption of a small domain like a Byte object be much more diverse and big than the original domain.

This is, with a Byte object we will have 256 possible values; but once encrypted, we will have much more. (And also we will need more space to store it, of course). Brute force won’t be that easy, here.

Regards,
Daniel.

About short data types – yes, they could be easier to brute force, but only if we didn't generate the encryption key with the enough strength. In PBE, if we follow the RSA standards (and jasypt does), for generating the encryption key, the password is added a (preferably random) salt, and then it is applied a hash function a number of times (iteration count).

The addition of a random salt, and the application of a hash function many times (RSA recommends at least 1,000) adds an important strength to the resulting encryption key (it is the same process as described in “Encrypting Passwords” in the jasypt website http://www.jasypt.org/encrypting-passwords.html), and, among other desirable effects, allow the domain of the result of the encryption of a small domain like a Byte object be much more diverse and big than the original domain.

This is, with a Byte object we will have 256 possible values; but once encrypted, we will have much more. (And also we will need more space to store it, of course). Brute force won't be that easy, here.

Regards,
Daniel.

Signatures requires a little more than asymmetric encryption, most notably, one has to consider where to store the actual signature. There’s also a danger of replay-attacks if you don’t include the primary key in the hash, so there are a few issues to consider to make it transparent. Nothing very impossible, though.

With regard to the different data types, have you analyzed whether encryption like this is appropriate for very short data types? It seems to me that the shorter the data type, the easier it will be to somehow brute force it. But I might have misunderstood the fundamentals of encryption here.

~Johannes

Signatures requires a little more than asymmetric encryption, most notably, one has to consider where to store the actual signature. There's also a danger of replay-attacks if you don't include the primary key in the hash, so there are a few issues to consider to make it transparent. Nothing very impossible, though.

With regard to the different data types, have you analyzed whether encryption like this is appropriate for very short data types? It seems to me that the shorter the data type, the easier it will be to somehow brute force it. But I might have misunderstood the fundamentals of encryption here.

~Johannes

If you mean adding asymmetric encryption techniques to jasypt, yes, that is in my to-do (maybe in a couple of versions). For the moment only message digests and password-based encryption are supported.

And by the way, version 1.2 of jasypt (to be released early in April) will add support for transparent hibernate encryption of: BigIntegers, BigDecimals, Bytes, Shorts, Integers, Longs, Floats, Doubles, Dates, Calendars, Booleans and byte[]’s (blobs). This way it will cover the full range of data types most frequently used for attributes of persistent entities.

Thanks for your interest.

Regards,
Daniel.

If you mean adding asymmetric encryption techniques to jasypt, yes, that is in my to-do (maybe in a couple of versions). For the moment only message digests and password-based encryption are supported.

And by the way, version 1.2 of jasypt (to be released early in April) will add support for transparent hibernate encryption of: BigIntegers, BigDecimals, Bytes, Shorts, Integers, Longs, Floats, Doubles, Dates, Calendars, Booleans and byte[]'s (blobs). This way it will cover the full range of data types most frequently used for attributes of persistent entities.

Thanks for your interest.

Regards,
Daniel.

These tools look real cool (and simple to use). Have you considered implementing signing data in the same way?

These tools look real cool (and simple to use). Have you considered implementing signing data in the same way?