"Jim Schaad (Exchange)" <jimsch(_at_)Exchange(_dot_)Microsoft(_dot_)com> writes:
1. Section 2.1. What is the timing you expect to see relative to PKCS5v2
being advanced to an RFC of some type?
I have no idea. Does it need to be? Like the other PKCS's I assume it can
be turned into an RFC in no time, but is that a requirement?
2. Section 2.1. The S/MIME working group is using 88 ASN syntax. The
syntax in this section is not. Please correct.
PKCS #5 uses current ASN.1 syntax and not the 1988 version, the ASN.1 used
is taken straight from the standard.
3. Section 2.1 Why is there ASN here that does not actually provide any
useful information. What are the parameters. What is the OID associated
with this set of parameters.
It's copied from PKCS #5 for completeness, I didn't want to include the
whole thing verbatim but did want to include enough information that readers
wouldn't have to keep flipping back and forth between the two.
4. Section 2.3.1 We have a key wrap algorithm specified in RFC 2630. You
are using a different key wrap algorithm. I would prefer to see a single
one for simplity of implementation. What is your justification for added
complexity?
The RFC 2630 algorithm doesn't work for anything other than fixed-length RC2
and 3DES keys. This algorithm works with anything (well, anything with an OID
defined, which in practice means pretty much any commonly-used algorithm).
It's also a lot simpler than the RFC 2630 algorithm, you just run any old
block cipher over the data twice without needing additional hashing, byte-
reversal, or anything else - if all you've got to do your crypto is a smart
card which does 3DES (eg Gemplus' MPCOS) or IDEA (see my previous message) you
can't even implement the RFC 2630 algorithm.
[I assume that when you're saying you can use 256 bits of key for a 128-bit
algorithm what you mean is that you have 256 bits of actual key which is
transformed to 128 bits of effective key by the RC2 key-transformation].
The same thing occurs with RFC 2630 and it doesn't seem to be a problem there.
In any case I think I've addressed it in "Special Handling for RC2 Keys".
6. Sectoin 2.3.1. Questions about your algorithm: 1) what is the IV that
should be used initially on the first pass encryption (not explicity stated
but implied later). 2) Where is the IV saved?
It's part of the AlgorithmIdentifier for the KEK algorithm. I assumed it
wouldn't be necessary to mention this because it's the standard usage for an IV
given in the AlgorithmIdentifier, but I can move the text in the example
(2.3.3, "Using the IV given in the KeyEncryptionAlgorithmIdentifer...") up to
2.3.1 if the current text isn't clear.
3) What does step 1 of section 2.3.2 do? I don't see a corresponding step
in section 2.3.1.
It recovers the IV used for the second pass of encrption (step 3 of 2.3.1).
This thing might work, but I should don't believe it from just reading the
document.
I would hope it does, or the people who have been using it almost daily since
it was first published in 1993 are in for a rude shock :-).
7. Section 2.3.4 -- Can this issue also be addressed by the addition of a
random salt to the KEK creation process? This means one is not using the
same KEK for every CEK encrption from a single password.
PKCS #5 already adds the salt, however I wanted to create a failsafe design
which works even if no salt (or a fixed salt) is used. The double-wrapping
also prevents bit-flipping attacks, I'll amend the text to mention this.
8. Section 2.4.1 -- You cannot change the CEK for RC2 in this document. I
don't want two different versions for this depending on wheither I have a
Password KEK mixed in the set of recipients. This just will not fly.
Uhhh... I don't understand the comment. How can you have two different CEK's
for the same data?
Peter.