eap Mailing List: RE: questions about PRF in eap-sim-11.txt

[Joseph Salowey (jsalowey]

Unfortunately this is not quite as trivial as it seems. The NIST
documents are confusing. 

Although the function G is derived from SHA-1 my interpretation of  FIPS
186-2 Appendix 3.3 is that it is slightly different.  In particular in
SHA-1 the length is appended to the message and in function G it is not.
The message block processed by SHA-1 is XKEY plus zero padding out to
512 bits with no message length appended. 

This also seems to be supported by the test vectors listed in:

http://csrc.nist.gov/CryptoToolkit/dss/Examples-1024bit.pdf

In re-reading the NIST specs I have to say that this is not all that
clear.  We definitely need to include a better description in the
appendix and some test vectors.  If you have a simpler way of expressing
this it would be great (or if you find that the spec actually uses
unmodified SHA-1). 

Thanks,

Joe



> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Michael Richardson
> Sent: Sunday, September 14, 2003 4:08 PM
> To: eap [at] frascone.com
> Subject: [eap] questions about PRF in eap-sim-11.txt
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> Section  17, page 50, says:
> 
>    Key derivation is based on the random number generation 
> specified in 
>    NIST Federal Information Processing Standards (FIPS) Publication 
>    186-2 [12]. The pseudo-random number generator is specified in the 
>    change notice 1 (2001 October 5) of [12] (Algorithm 1). As 
> specified 
>    in the change notice (page 74), when Algorithm 1 is used as a 
>    general-purpose pseudo-random number generator, the "mod 
> q" term in 
>    step 3.3 is omitted. The function G used in the algorithm is 
>    constructed via Secure Hash Standard as specified in 
> Appendix 3.3 of 
> *  the standard. For convenience, the random number algorithm 
> with the 
>    correct modification is cited in Annex B.  
>     
>    160-bit XKEY and XVAL values are used, so b = 160. On each full 
>    authentication, the Master Key is used as the initial secret seed-
>    key XKEY. The optional user input values (XSEED_j) in step 3.1 are 
>    set to zero.  
>     
> May I suggest that annex B be actually fully edited to 
> reflect all of these settings?
> 
> In *, I assume it is a reference to 186-2?
> 
> We need a total of K_encr(128 bits), K_aut(128 bits), MSK(64 
> bytes), EMSK(64 bytes). A total of 1280 bytes, or m = 4.
> 
> So, the algorithm would become:
> 
>         let XKEY := MK,
>             XSEED_j := 0
> 
>    Step 3: For j = 0 to 3 do 
>              a. XVAL = XKEY 
>              b. w_0 = SHA1(XVAL) 
>              c. XKEY = (1 + XKEY + w_0) mod 2^160
>              d. XVAL = XKEY 
>              e. w_1 = SHA1(XVAL) 
>              f. XKEY = (1 + XKEY + w_1) mod 2^160
>          3.3 x_j = w_0|w_1 
> 
> Assuming that I'm correct, I would strongly suggest that this 
> be documented in this way. This makes it trivial to code 
> without wandering through 150 pages of FIPS documents. 
> 
> ]      Out and about in Ottawa.    hmmm... beer.              
>   |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON  
>   |net architect[
> ] mcr [at] sandelman.ottawa.on.ca 
> http://www.sandelman.ottawa.on.ca/ |device > driver[ ] 
> panic("Just another Debian/notebook using, kernel hacking, 
> security guy");  [
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Finger me for keys - custom hacks make this fully PGP2 compat
> 
> iQCVAwUBP2T0rYqHRg3pndX9AQENtgP/ep9cRmhDycJOrq9M3HYBncKOJBRBxsgK
> MZoutlwGJ2oXdQZRTaRaPkDdDnCnOLIiwvonucG0OfRz1AB6gmodZU+Zm3wpXjTM
> y0ymFKFnyjTdw+wpHfaOHDqu2XMRBA9sBbcVRUbOF/qlXgyyjcRYzf/oj5ORF1O/
> 7zxY5Up3Kn4=
> =D0m6
> -----END PGP SIGNATURE----- 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>