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

[kerberos@noopy.org]

On Thu, Oct 15, 2009 at 10:03 AM, Greg Hudson <ghudson at mit.edu> wrote:
> On Tue, 2009-10-13 at 15:42 -0400, kerberos at noopy.org wrote:
>> 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?
>
> You have the right idea to the best of my understanding, with the
> proviso that you should be using the cipher's default input vector
> (which I believe is all-bits-zero) and not an IV left over from any
> previous encryption.  So, I'm not immediately sure why you're not
> getting the right result.

*blushing* I figured out the error of my ways this morning.
Apparently some code I'd added for debugging was reading the result
Rfc2898DeriveBytes(...) *twice*, like so:

  Rfc2898DeriveBytes k1 = new Rfc2898DeriveBytes(passPhrase,
saltValueBytes, passwordIterations);
  Console.WriteLine("debug me: " +
BitConverter.ToString(k1.GetBytes(keySize / 8))); // correct result
  byte[] keyBytes = k1.GetBytes(keySize / 8);
  Console.WriteLine(BitConverter.ToString(keyBytes)); // wrong result

The end result of calling GetBytes(...) twice was that my
intermediate/temporary key was flat *wrong* (as it was generated by
having read twice as many bits as it should've been) and this caused
my DK(...) function to fail.

I modified my code like so:

  Rfc2898DeriveBytes k1 = new Rfc2898DeriveBytes(passPhrase,
saltValueBytes, passwordIterations);
  byte[] keyBytes = k1.GetBytes(keySize / 8);
  Console.WriteLine(BitConverter.ToString(keyBytes)); // correct result

Then I went back to each of the test vectors in RFC 3962 and
everything matched up.  Then I went back and compared to output of
ktpass.exe and everything matched up.  Sweet.  :-)

Thanks everyone for your clarification.  Very helpful!

-- 
K