Jim Schaad (Exchange) wrote:
[Stuff suggesting one seriously annoyed Jim deleted]
I had completely missed the sentences that put restrictions on the message
encryption algorithm if certain transport algorithms are used. I THINK THIS
IS WRONG!!!!! If I had understood at the time that this was the proposal I
would have been very vocal about this. This was introduced post draft 3 of
section 12 on the list. I may have just missed it.
Speaking personally I can live with things as suggested. However they
would make my life bloody difficult and I'd rather not have to.
Given this I STRONGLY suggest that we
1) remove the offending sentences
2) keep the fixed 128-bit keys size when creating the key wraping key
3) fix the wraping algorithm by adding a known padding mechisim. (Three
alternatives: a) add a size byte, b) use the standard content encryption
alg, c) use a modified PKCS#1 with a NULL byte followed by random pad)
I agree with all that and again speaking personally I'd go with b) for
the following reasons.
Certain libraries have the separate algorithms corresponding to "raw"
and "padded" versions: for example in PKCS#11 we have CKM_RC2_CBC and
CKM_RC2_CBC_PAD (this uses padding compatible with standard content
encryption padding described in CMS 6.3).
As things stand there would be two seprate versions, RC2 as used for
content encryption (with padding) and RC2 as used in key wrap (no
padding). If we take option b) then we consistently end up with the same
padding used for both wrapping and content encryption. As a nice side
effect this also allows the key length to be determined unambiguously.
If adding pseudo-random bytes is still considered necessary then adding
a fixed number (e.g. one block length) still allows the key length to be
determined.
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.