You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Leo Li (JIRA)" <ji...@apache.org> on 2007/11/15 04:13:43 UTC
[jira] Created: (DIRSERVER-1100)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
cannot decrypt the encryptiondata it generated.
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption cannot decrypt the encryptiondata it generated.
-------------------------------------------------------------------------------------------------------------------------------------------
Key: DIRSERVER-1100
URL: https://issues.apache.org/jira/browse/DIRSERVER-1100
Project: Directory ApacheDS
Issue Type: Bug
Components: kerberos
Reporter: Leo Li
Here is an example:
import javax.security.auth.kerberos.KerberosKey;
import javax.security.auth.kerberos.KerberosPrincipal;
import org.apache.directory.server.kerberos.shared.messages.value.EncryptedData;
import org.apache.directory.server.kerberos.shared.messages.value.EncryptionKey;
import org.apache.directory.server.kerberos.shared.crypto.encryption.*;
public static void main(String[] args) throws Exception{
final char[] PASSWORD = "PASSWORD".toCharArray();
KerberosKey key = new KerberosKey(new KerberosPrincipal("servicetest@EXAMPLE.COM"),PASSWORD, "DES");
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);
System.out.println("Succeed!");
}
But it fails with such complain:
Exception in thread "main" org.apache.directory.server.kerberos.shared.exceptions.KerberosException: Integrity check on decrypted field failed
at org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption.getDecryptedData(DesCbcCrcEncryption.java:113)
at TestDESCBCCRC.main(TestDESCBCCRC.java:21)
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.
[jira] Assigned: (DIRSERVER-1100)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
cannot decrypt the encryptiondata it generated.
Posted by "Enrique Rodriguez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrique Rodriguez reassigned DIRSERVER-1100:
--------------------------------------------
Assignee: Enrique Rodriguez
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption cannot decrypt the encryptiondata it generated.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1100
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1100
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
> Reporter: Leo Li
> Assignee: Enrique Rodriguez
> Attachments: Directory_100.diff
>
>
> Here is an example:
> import javax.security.auth.kerberos.KerberosKey;
> import javax.security.auth.kerberos.KerberosPrincipal;
> import org.apache.directory.server.kerberos.shared.messages.value.EncryptedData;
> import org.apache.directory.server.kerberos.shared.messages.value.EncryptionKey;
> import org.apache.directory.server.kerberos.shared.crypto.encryption.*;
> public static void main(String[] args) throws Exception{
> final char[] PASSWORD = "PASSWORD".toCharArray();
> KerberosKey key = new KerberosKey(new KerberosPrincipal("servicetest@EXAMPLE.COM"),PASSWORD, "DES");
> 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);
> System.out.println("Succeed!");
> }
> But it fails with such complain:
> Exception in thread "main" org.apache.directory.server.kerberos.shared.exceptions.KerberosException: Integrity check on decrypted field failed
> at org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption.getDecryptedData(DesCbcCrcEncryption.java:113)
> at TestDESCBCCRC.main(TestDESCBCCRC.java:21)
> 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.
[jira] Closed: (DIRSERVER-1100)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
cannot decrypt the encryptiondata it generated.
Posted by "Enrique Rodriguez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrique Rodriguez closed DIRSERVER-1100.
----------------------------------------
Resolution: Fixed
Fix Version/s: bigbang
Corrected padding algorithm error in DES encryption types (DIRSERVER-1100):
o Corrected padding algorithm error in DesCbcCrcEncryption.
o Also corrected padding algorithm error in DesCbcMd5Encryption, however algorithm error had no effect.
o Added new test cases for above encryption types.
Committed to kerberos-shared module in 'bigbang' branch on revision 597792.
http://svn.apache.org/viewcvs.cgi?view=rev&rev=597792
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption cannot decrypt the encryptiondata it generated.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1100
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1100
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
> Reporter: Leo Li
> Assignee: Enrique Rodriguez
> Fix For: bigbang
>
> Attachments: Directory_100.diff
>
>
> Here is an example:
> import javax.security.auth.kerberos.KerberosKey;
> import javax.security.auth.kerberos.KerberosPrincipal;
> import org.apache.directory.server.kerberos.shared.messages.value.EncryptedData;
> import org.apache.directory.server.kerberos.shared.messages.value.EncryptionKey;
> import org.apache.directory.server.kerberos.shared.crypto.encryption.*;
> public static void main(String[] args) throws Exception{
> final char[] PASSWORD = "PASSWORD".toCharArray();
> KerberosKey key = new KerberosKey(new KerberosPrincipal("servicetest@EXAMPLE.COM"),PASSWORD, "DES");
> 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);
> System.out.println("Succeed!");
> }
> But it fails with such complain:
> Exception in thread "main" org.apache.directory.server.kerberos.shared.exceptions.KerberosException: Integrity check on decrypted field failed
> at org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption.getDecryptedData(DesCbcCrcEncryption.java:113)
> at TestDESCBCCRC.main(TestDESCBCCRC.java:21)
> 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.
[jira] Updated: (DIRSERVER-1100)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
cannot decrypt the encryptiondata it generated.
Posted by "Leo Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leo Li updated DIRSERVER-1100:
------------------------------
Attachment: Directory_100.diff
Hi, all
Will somebody have a look at it.
If it works, maybe I shall append a testcase.:)
Thanks,
Leo.
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption cannot decrypt the encryptiondata it generated.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1100
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1100
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
> Reporter: Leo Li
> Attachments: Directory_100.diff
>
>
> Here is an example:
> import javax.security.auth.kerberos.KerberosKey;
> import javax.security.auth.kerberos.KerberosPrincipal;
> import org.apache.directory.server.kerberos.shared.messages.value.EncryptedData;
> import org.apache.directory.server.kerberos.shared.messages.value.EncryptionKey;
> import org.apache.directory.server.kerberos.shared.crypto.encryption.*;
> public static void main(String[] args) throws Exception{
> final char[] PASSWORD = "PASSWORD".toCharArray();
> KerberosKey key = new KerberosKey(new KerberosPrincipal("servicetest@EXAMPLE.COM"),PASSWORD, "DES");
> 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);
> System.out.println("Succeed!");
> }
> But it fails with such complain:
> Exception in thread "main" org.apache.directory.server.kerberos.shared.exceptions.KerberosException: Integrity check on decrypted field failed
> at org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption.getDecryptedData(DesCbcCrcEncryption.java:113)
> at TestDESCBCCRC.main(TestDESCBCCRC.java:21)
> 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.
[jira] Commented: (DIRSERVER-1100)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
cannot decrypt the encryptiondata it generated.
Posted by "Enrique Rodriguez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542938 ]
Enrique Rodriguez commented on DIRSERVER-1100:
----------------------------------------------
I have this verified and fixed, with new test cases. I just need to get to email to double-check where to commit it and to verify commit messages and CI.
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption cannot decrypt the encryptiondata it generated.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1100
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1100
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
> Reporter: Leo Li
> Assignee: Enrique Rodriguez
> Attachments: Directory_100.diff
>
>
> Here is an example:
> import javax.security.auth.kerberos.KerberosKey;
> import javax.security.auth.kerberos.KerberosPrincipal;
> import org.apache.directory.server.kerberos.shared.messages.value.EncryptedData;
> import org.apache.directory.server.kerberos.shared.messages.value.EncryptionKey;
> import org.apache.directory.server.kerberos.shared.crypto.encryption.*;
> public static void main(String[] args) throws Exception{
> final char[] PASSWORD = "PASSWORD".toCharArray();
> KerberosKey key = new KerberosKey(new KerberosPrincipal("servicetest@EXAMPLE.COM"),PASSWORD, "DES");
> 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);
> System.out.println("Succeed!");
> }
> But it fails with such complain:
> Exception in thread "main" org.apache.directory.server.kerberos.shared.exceptions.KerberosException: Integrity check on decrypted field failed
> at org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption.getDecryptedData(DesCbcCrcEncryption.java:113)
> at TestDESCBCCRC.main(TestDESCBCCRC.java:21)
> 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.