[
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.
