decryption of encrypted DB2 UDB LUW column without using DB2 decrypt function

[Bernard Dhooghe]

The information center writes:

"Encryption Algorithm: The internal encryption algorithm used is RC2
block cipher with padding, the 128-bit secret key is derived from the
password using a MD2 message digest.
"

and also explains how the length of the encrypted column can be
derived.

How to understand this explanation so that encrypted column data could
be decrypted without using the decrypt routine?

First the MD2 explanation: the 128-bit secret key is derived from the
password using a MD2 message digest:

How is the MD2 derived from the password?

And also:

For encrypted data with no hint:

"
maximum length of the non-encrypted data + 8 bytes + the number of
bytes to the next 8 byte boundary = encrypted data column length.
"
RC2 is a 8 bytes block size algorithm. What is the padding of the data
and what are the extra 8-bytes?

And how is the hint implemented?
Bernard Dhooghe

[Phil Sherman]

Bernard Dhooghe wrote:

The information center writes:

"Encryption Algorithm: The internal encryption algorithm used is RC2
block cipher with padding, the 128-bit secret key is derived from the
password using a MD2 message digest.
"

and also explains how the length of the encrypted column can be
derived.

How to understand this explanation so that encrypted column data could
be decrypted without using the decrypt routine?

The objective of encryption is to not allow viewing the data without
using the decryption routine. If you really want to do this, you need to
contact the codebreaking staff at the United States NSA (National
Security Agency). Be prepared for visits from a number of different
government agencies if you do this.

>
First the MD2 explanation: the 128-bit secret key is derived from the
password using a MD2 message digest:

How is the MD2 derived from the password?

The password is fed into the MD2 hashing algorithm which should append a
checksum to the password then hashes the result into a 32 bit field. The
objective of the hash is to make a unique "signature" that the
password/checksum generates that no other password will generate the
same "signature" . The combination of password and the checksum make it
very difficult to find another password that will yield the same 32 bit
result.

As an aside, the use of MD2 is interesting. It is an algorithm optimized
for 8-bit processors. Other digesting mechanisms for 32-bit
architectures should have better performance. The choice of MD2 may have
been influenced by U.S. export restrictions on cryptographic mechanisms.

>
And also:

For encrypted data with no hint:

"
maximum length of the non-encrypted data + 8 bytes + the number of
bytes to the next 8 byte boundary = encrypted data column length.
"
RC2 is a 8 bytes block size algorithm. What is the padding of the data
and what are the extra 8-bytes?

RC2 works on 8 bytes of data at a time. If the data to be encrypted is
not a multiple of 8 then the data must be padded out to the next
multiple of 8.

The RC2 combines the password digest with a "salt" to further expand the
encryption key. The salt is always sent, unencrypted, with the encrypted
message. Salts range from 40 to 88 bits so I'd suspect the eight extra
bytes are a 64 bit (or less) salt value.
http://www.rsasecurity.com/rsalabs/node.asp?id=2249

>
And how is the hint implemented?

The hint is stored (unencrypted) with the encrypted data. Pass the
encrypted data to the GETHINT scalar function to retrieve the hint.
Present it to the user and then ask the user for the password.

>
Bernard Dhooghe

It's more likely that your user will forget the password and you won't
be able to retrieve the data. If this is a concern, then you must
implement some password mechanism that will force your users to store
passwords in a secure "vault" that can be opened with appropriate
authorization. The only way I know of to do this, where multiple users
access a database, involves the use of asymetric encryption which uses
different keys to encrypt and decrypt. This type of encryption is many
many times slower than the symmetrical encryption technique implemented
in DB2 and is not suitable for high performance applications.

Phil Sherman

[Bernard Dhooghe]

I also think the choosen implementation is just not to see the data
without some extra coding/control, together with a performant
implementation.

The question is how to decrypt columns, having access to the password,
but not using the DB2 routines.

The algorithms used are well known, this is not a real problem, just
the correct data feed.

The Information Center writes:

"Administra tion of encrypted data: Encrypted data can only be decrypted
on servers that support the decryption functions corresponding to the
ENCRYPT function."
"

Correct:

followed by:

"
Therefore, replication of columns with encrypted data should only be
done to servers that support the DECRYPT_BIN or the DECRYPT_CHAR
function.
"

to be completed with: 'or servers implementing decrypt functions
corresponding to the ENCRYPT function'.
Bernard Dhooghe

Phil Sherman wrote:

Bernard Dhooghe wrote:

The information center writes:

"Encryption Algorithm: The internal encryption algorithm used is RC2
block cipher with padding, the 128-bit secret key is derived from the
password using a MD2 message digest.
"

and also explains how the length of the encrypted column can be
derived.

How to understand this explanation so that encrypted column data could
be decrypted without using the decrypt routine?

The objective of encryption is to not allow viewing the data without
using the decryption routine. If you really want to do this, you need to
contact the codebreaking staff at the United States NSA (National
Security Agency). Be prepared for visits from a number of different
government agencies if you do this.

First the MD2 explanation: the 128-bit secret key is derived from the
password using a MD2 message digest:

How is the MD2 derived from the password?

The password is fed into the MD2 hashing algorithm which should append a
checksum to the password then hashes the result into a 32 bit field. The
objective of the hash is to make a unique "signature" that the
password/checksum generates that no other password will generate the
same "signature" . The combination of password and the checksum make it
very difficult to find another password that will yield the same 32 bit
result.

As an aside, the use of MD2 is interesting. It is an algorithm optimized
for 8-bit processors. Other digesting mechanisms for 32-bit
architectures should have better performance. The choice of MD2 may have
been influenced by U.S. export restrictions on cryptographic mechanisms.

And also:

For encrypted data with no hint:

"
maximum length of the non-encrypted data + 8 bytes + the number of
bytes to the next 8 byte boundary = encrypted data column length.
"
RC2 is a 8 bytes block size algorithm. What is the padding of the data
and what are the extra 8-bytes?

RC2 works on 8 bytes of data at a time. If the data to be encrypted is
not a multiple of 8 then the data must be padded out to the next
multiple of 8.

The RC2 combines the password digest with a "salt" to further expand the
encryption key. The salt is always sent, unencrypted, with the encrypted
message. Salts range from 40 to 88 bits so I'd suspect the eight extra
bytes are a 64 bit (or less) salt value.
http://www.rsasecurity.com/rsalabs/node.asp?id=2249

And how is the hint implemented?

The hint is stored (unencrypted) with the encrypted data. Pass the
encrypted data to the GETHINT scalar function to retrieve the hint.
Present it to the user and then ask the user for the password.

Bernard Dhooghe

It's more likely that your user will forget the password and you won't
be able to retrieve the data. If this is a concern, then you must
implement some password mechanism that will force your users to store
passwords in a secure "vault" that can be opened with appropriate
authorization. The only way I know of to do this, where multiple users
access a database, involves the use of asymetric encryption which uses
different keys to encrypt and decrypt. This type of encryption is many
many times slower than the symmetrical encryption technique implemented
in DB2 and is not suitable for high performance applications.

Phil Sherman