RFC 3962 and DK(tkey, "kerberos") function

[kerberos@noopy.org]

Hello,

Thanks for your response!  Further stuff inline.

On Fri, Oct 9, 2009 at 12:28 PM, Tom Yu <tlyu at mit.edu> wrote:
>
> The IV is also known as the "cipher state" for CBC ciphers, and each
> cryptosystem specification includes a default initial cipher state.
> For "simplified profile" (e.g. DES3 and AES) cryptosystems, this is
> all-bits-zero.

OK.

>
> The DK function uses n-fold to expand the well-known constant
> "kerberos" to a full cipher block length and then uses a temporary key
> to encrypt that block.  It does not use the n-folded constant as an
> IV.  In the case of AES, the temporary key is the output of PBKDF2.
>

When using the following from test vectors as written in
http://www.apps.ietf.org/rfc/rfc3962.html Appendix B, Example 1
(Iteration count = 1, Pass phrase = "password", Salt =
"ATHENA.MIT.EDUraeburn"):
  - My Rfc2898DeriveBytes(...) function matches the 128-bit PBKDF2
output when I use the values above.
  - My N-fold function for "kerberos" matches the test vectors for
128-fold "kerberos" in
http://www.apps.ietf.org/rfc/rfc3961.html#sec-A.1.

My 128-bit AES key *doesn't* match the one in
http://www.apps.ietf.org/rfc/rfc3962.html Appendix B, Example 1.  I'm
not clear why this is happening -- but suspect the problem lies
somewhere in what I'm encrypting rather than in creating a temporary
key or in my n-folding function.  Basically what I'm trying to do in
my DK function is: "encrypt my 'kerberos' block with the temporary key
I got from my derive bytes function."

Am I understanding how I create the final key correctly here?

-- 
K