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/12/05 08:41:43 UTC
[jira] Created: (DIRSERVER-1107)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
--------------------------------------------------------------------------------------------------------------------------------------------------------
Key: DIRSERVER-1107
URL: https://issues.apache.org/jira/browse/DIRSERVER-1107
Project: Directory ApacheDS
Issue Type: Bug
Reporter: Leo Li
As in RFC3961 [Page 17]:
6.1.3. CRC-32 Checksum
This CRC-32 checksum calculates a checksum based on a cyclic
redundancy check as described in ISO 3309 [CRC] but modified as
described below.
...
The CRC-32 checksum used in the des-cbc-crc encryption mode is
identical to the 32-bit FCS described in ISO 3309 with two
exceptions: The sum with the all-ones polynomial times x**k is
omitted, and the final remainder is not ones-complemented. ISO 3309
describes the FCS in terms of bits, whereas this document describes
the Kerberos protocol in terms of octets. To clarify the ISO 3309
definition for the purpose of computing the CRC-32 in the des-cbc-crc
encryption mode, the ordering of bits in each octet shall be assumed
to be LSB first. Given this assumed ordering of bits within an
octet, the mapping of bits to polynomial coefficients shall be
identical to that specified in ISO 3309.
And RFC 3961 also gives test data in its Appendix A.5:
RFC 3961 Encryption and Checksum Specifications February 2005
internally for such a number is irrelevant; the octet sequence
generated is what is important.)
mod-crc-32("foo") = 33 bc 32 73
mod-crc-32("test0123456789") = d6 88 3e b8
mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
mod-crc-32(8000) = 4b 98 83 3b
mod-crc-32(0008) = 32 88 db 0e
mod-crc-32(0080) = 20 83 b8 ed
mod-crc-32(80) = 20 83 b8 ed
mod-crc-32(80000000) = 3b b6 59 ed
mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRKRB-27)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
Posted by "Richard Feezel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRKRB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909726#action_12909726 ]
Richard Feezel commented on DIRKRB-27:
--------------------------------------
I am attaching a proposed patch for Crc32Checksum.java. I have run the tests, shown as comments at the end of the file, and the values are correct. With this patch applied I have run "mvn test -Dintegration" without error but I do not believe that this code is actually tested by any of the JUnit tests. I'm not sure how to go about created a test case that proves interoperability with independent Kerberos clients. It seems to me that we need a set of tests which exercise Kerberos authentication in all the supported cryptographic modes, perhaps by using the Java javax.security.auth.login.LoginContext Kerberos login. I'm not yet familiar enough with it, however, to know how to configure the server and the client classes to accomplish this.
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRKRB-27
> URL: https://issues.apache.org/jira/browse/DIRKRB-27
> Project: Directory Kerberos
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Leo Li
> Fix For: 2.0.0
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRKRB-27)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRKRB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910365#action_12910365 ]
Emmanuel Lecharny commented on DIRKRB-27:
-----------------------------------------
I'm wondering if the Java CRC32 class can be used in this case ?
http://download.oracle.com/javase/6/docs/api/java/util/zip/CRC32.html
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRKRB-27
> URL: https://issues.apache.org/jira/browse/DIRKRB-27
> Project: Directory Kerberos
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Leo Li
> Assignee: Emmanuel Lecharny
> Fix For: 2.0.0
>
> Attachments: Crc32Checksum.patch
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-1107)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-1107:
-----------------------------------------
Fix Version/s: 2.0.0-RC1
(was: 2.0.0)
Moved back to 2.0.0-RC1
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1107
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1107
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.1
> Reporter: Leo Li
> Fix For: 2.0.0-RC1
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-1107)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
Posted by "Kiran Ayyagari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kiran Ayyagari updated DIRSERVER-1107:
--------------------------------------
Fix Version/s: 2.0.0
(was: 2.0.0-RC1)
Moving to 2.0
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1107
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1107
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.1
> Reporter: Leo Li
> Fix For: 2.0.0
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-1107)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-1107:
-----------------------------------------
Affects Version/s: 1.5.1
Fix Version/s: 2.0.0
No time to include a fix for this issue before 2.0
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1107
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1107
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.1
> Reporter: Leo Li
> Fix For: 2.0.0
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRKRB-27)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
Posted by "Richard Feezel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRKRB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Feezel updated DIRKRB-27:
---------------------------------
Attachment: Crc32Checksum.patch
Suggested patch to correctly implement CRC-32 in the Kerberos Checksums.
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRKRB-27
> URL: https://issues.apache.org/jira/browse/DIRKRB-27
> Project: Directory Kerberos
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Leo Li
> Fix For: 2.0.0
>
> Attachments: Crc32Checksum.patch
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRKRB-27)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRKRB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny reassigned DIRKRB-27:
---------------------------------------
Assignee: Emmanuel Lecharny
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRKRB-27
> URL: https://issues.apache.org/jira/browse/DIRKRB-27
> Project: Directory Kerberos
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Leo Li
> Assignee: Emmanuel Lecharny
> Fix For: 2.0.0
>
> Attachments: Crc32Checksum.patch
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRKRB-27)
[kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
shall not use java.util.zip.CRC32 to generate CRC32 checksum
Posted by "Richard Feezel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRKRB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910542#action_12910542 ]
Richard Feezel commented on DIRKRB-27:
--------------------------------------
java.util.zip.CRC32, according to the original submitter of this issue, does not implement the modified version of ISO-3309 as used by Kerberos. Thus the need for an alternative. The existing code tries to use java.util.zip.CRC32 but appears to be disabled, I assume because it doesn't work right (inter-operate with MIT Kerberos). Yesterday I made the necessary modifications to use my alternative CRC-32 implementation in the des-cbc-crc code but haven't gotten it to successfully inter-operate with the Sun Kerberos login yet. I'll work on it some more today hopefully.
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRKRB-27
> URL: https://issues.apache.org/jira/browse/DIRKRB-27
> Project: Directory Kerberos
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Leo Li
> Assignee: Emmanuel Lecharny
> Fix For: 2.0.0
>
> Attachments: Crc32Checksum.patch
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.