You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2010/05/26 14:27:14 UTC
[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
[ 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.