directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li (JIRA)" <>
Subject [jira] Created: (DIRSERVER-1100) [kerberos] cannot decrypt the encryptiondata it generated.
Date Thu, 15 Nov 2007 03:13:43 GMT
cannot decrypt the encryptiondata it generated.

                 Key: DIRSERVER-1100
             Project: Directory ApacheDS
          Issue Type: Bug
          Components: kerberos
            Reporter: Leo Li

Here is an example:



public static void main(String[] args)  throws Exception{
       final char[] PASSWORD = "PASSWORD".toCharArray();
       KerberosKey key = new KerberosKey(new KerberosPrincipal("servicetest@EXAMPLE.COM"),PASSWORD,
       byte[] keyBytes = key.getEncoded();
       EncryptionKey encryptionKey = new EncryptionKey(EncryptionType.DES_CBC_CRC, keyBytes);
       byte[] plainText = {1,2,3,4,5,6,7};
       DesCbcCrcEncryption encryption = new DesCbcCrcEncryption();
       EncryptedData encryptionData = encryption.getEncryptedData(encryptionKey, plainText,
KeyUsage.NUMBER1); // I am not sure of  which KeyUsage should use here, but it is not referenced
in source code. So I think any will work.
       encryption.getDecryptedData(encryptionKey, encryptionData, KeyUsage.NUMBER1);

But it fails with such complain:

Exception in thread "main"
Integrity check on decrypted field failed
	at TestDESCBCCRC.main(

After I look a further into it,  it is due to current implementation (r595192) there is two
paddings in DesCbcCrcEncryption.getEncryptedData:

LINE 126: 
       byte[] paddedPlainText = padString( plainText );
        byte[] dataBytes = concatenateBytes( conFounder, concatenateBytes( zeroedChecksum,
paddedPlainText ) );
        byte[] checksumBytes = calculateIntegrity( dataBytes, null, usage );
        byte[] paddedDataBytes = padString( dataBytes );

But RFC 3961 
"One generates a random confounder of one block, placing it in
   'confounder'; zeros out the 'checksum' field (of length appropriate
   to exactly hold the checksum to be computed); adds the necessary
   padding; calculates the appropriate checksum over the whole sequence,
   placing the result in 'checksum'; and then encrypts using the
   specified encryption type and the appropriate key."

So the checksum should be calculated after all padding for encryption has finished.
It seems that the same problem occurs in other Encryption classes.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message