ietf-smime
[Top] [All Lists]

X9.42 comments.

1999-05-22 13:06:50
As an initial step to implementing S/MIME v3 I started examining X9.42
at length with a view to implementing DH certificates support (which may
well end up in OpenSSL at some point). Previously I'd only verified the
KEK generation examples and not started on a full implementation.

I assume there are no examples available yet? By examples I mean
examples of key pairs, parameters, SEED values and shared secrets that
is: not just the KEK generation stuff which is already present.

A few things have cropped up: maybe some more will crop up during
(attempted) implementation. My appologies in advance for mentioning them
at this late stage, but there are certain things that only crop up when
you try to implement the algorithm.

All in section 2.2.1.1

Firstly at the start:

Let L - 1 = n*m + b where both b and n are integers and 0 <= b < 160.

For arbitrary values of L and m this cannot always be satisfied. I'm not
100% sure but I think this should be:

"Let L - 1 = n*160 + b where both b and n are integers and 
0 <= b < 160"

which is the same as FIPS186. The reason being 'n' and 'b' are used to
generate 'W' (and ultimately p) by adding together 160 bit "chunks" in
step 10. The "160" here comes from the size of an SHA digest.

Then step 4:

4. for i = 0 to m' - 1

U = U + SHA[SEED + i] XOR SHA[(SEED + m' + i) mod 2^160] *
2^(160 * i)

Note that for m=160, this reduces to the algorithm of [FIPS-186]

U = SHA[SEED] XOR SHA[(SEED+1) mod 2^160 ]."

Presumably SHA refers to SHA-1? 

My copy of FIPS-186 has (mod 2^g) in it (g is size of seed in bits) not
(mod 2^160). As things stand (mod 2^160) is effectively throwing away
the first g-160 bits of SEED, whereas (mod 2^g) is discarding any carry
(which is admittedly rather unlikely).

Anyway for completeness should the carry be discarded on the first part
as well? So the complete thing would read:

U = U + SHA[(SEED + i)mod 2^g] XOR SHA[(SEED + m' + i) mod 2^g] * 2^(160
* i)

Otherwise there is a very unlikely posibility that SEED + i will be
longer than SEED (but this case is excluded in the second SHA anyway).

Couple more things. The use of g for two separate things is a little
confusing: size of SEED in bits and one of the DH parameters. Though
FIPS186 does this as well.

Presumably the size of SEED in bits must be a multiple of 8? Since SEED
is represented as a BIT STRING (see PKIX) this need not be so. I assume
the "no trailing zero bits" DER encoding rule doesn't apply here:
otherwise there will be possible ambiguity.

Finally step 10 seems a bit garbled: there are a few ^ missing.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: drh(_at_)celocom(_dot_)com PGP key: via homepage.


<Prev in Thread] Current Thread [Next in Thread>