Key derivation with non-ASCII characters

[Frank Taylor]

Many thanks for this information!

Some initial testing shows that this works. My AD is set to codepage
437 (US), which encodes a pound sign as 0x9c (156). I set the password
on the AD itself so there are no problems with differing codepage
settings. Converting the secret£ password using this encoding produces
the right DES key.

RESULT -----------------------------------------------------
RESULT Password:  secret£DEV.PROPERO.INTpaeuser1
RESULT Bytes:     73 65 63 72 65 74 9c 44 45 56 2e 50 52 4f 50 45 52
4f 2e 49 4e 54 70 61 65 75 73 65 72 31
RESULT Method:    Boolean[64]
RESULT Generated: 202ba9bfe70ad37
RESULT Wanted:    202ba9bfe70ad37
RESULT Outcome:   PASS
RESULT -----------------------------------------------------

Many thanks to all who have helped track this information down... now
I need to go off and figure out what to do with it!

Frank.

Jeffrey Altman <jaltman2 at nyc.rr.com> wrote in message news:<415039BD.7010109 at nyc.rr.com>...
> Thanks to Microsoft we have an answer to this question.
> Apparently, Windows does not use UTF-8 for the DES string to key
> operations.  UTF-8 is only used for RC4-HMAC.
> 
> In the DES string to key operations, the current locally defined
> OEM Code Page is used.
> 
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\OEMCP.
> 
> Of course, this can result in all of the problems associated with 
> non-ASCII characters as described in Kerberos Clarifications if the
> OEM Code Page of the client does not match the character-set of the
> KDC.
> 
> If you are going to use DES keys you had better stick to ASCII only
> names.
> 
> Jeffrey Altman