Blake Ramsdell wrote:
Just so we're clear, my understanding is that the MEK works fine in both
DH and RSA right now as-is. The only question is regarding the KEK
which is not used in RSA, and is the only thing that is currently
ambiguous due to the mechanism by which those keys are generated.
The use of the current RC2 MEK mechanism should work fine in both DH and
RSA environments, as well as a mix of the two.
Unfortunately the current key wrapping spec says:
"5. Generate the number of pad octets necessary to make the
result a multiple of the key-encryption algorithm block
size, then append them to the result."
Which doesn't allow the MEK key length to be determined unambiguously.
Well at least the way I read it it doesn't anway.
The only problem here (which may be due to my missing the latest key
wrapping spec) is that the key wrapping spec doesn't allow
the length of
the "packaged" wrapped key to be unambiguously determined (except
through trial and error): my suggestion (in another message)
about using
PKCS padding would fix that though.
Shouldn't it just be regular ol' block padding? You're using a
symmetric block cipher to protect the data. I think that for RC2 this
is an 8 byte block, so the "eight bytes of eight" or "one byte of one"
etc. is the padding, right?
Yeah thats what I mean. I think PKCS#11 calls it "PKCS padding". Anyway
whatever you call it that's what I meant.
So from all this I'd personally be happy with
1. MEK: not specified, doesn't matter.
2. KEK: specified as either fixed or X/8.
3. Ammend wrapping standard to use standard block padding.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.