directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Feezel (JIRA)" <j...@apache.org>
Subject [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
Date Wed, 15 Sep 2010 13:33:32 GMT

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


Mime
View raw message