RFC 3962 and DK(tkey, "kerberos") function
kerberos@noopy.org
kerberos at noopy.org
Thu Oct 15 10:53:59 EDT 2009
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
More information about the Kerberos
mailing list