-----Original Message-----
From: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz
[mailto:pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz]
"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?
It is my understanding that if you want this document to following standards
track, you are not going to be able to reference a non-fixed document. The
PKCS documents have not meet that criteria in the past and thus the reason
why we got them published as informational to get the S/MIME v2 drafts in.
I believe this is also a requirement for publishing the password draft as
informational as well but am not sure. Therefore this is a blocking factor
for moving the document forward.
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.
I believe that you failed at this. There is not enough information in this
draft to know anything. For all of the good what is there did me, you might
as well have omitted it entirely for all of the good it did me when reading
the draft.
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".
That's an interesting statement. I explicitly worked with Russ to make sure
that we could do variable length RC2 keys using the key wrap algorithm from
RFC 2630. I find it difficult to believe that your algorithm is "much"
simpler than the one in RFC2630 given the partial decryptions and so forth.
(I don't know it is really alot harder either.) Given that most people
implemented the one in RFC2630 in a couple of hours at most I don't see that
complexity of implemenation is real hard. Also given that the new CAST and
IDEA drafts both use the RFC2630 key wrapping algorithm makes me believe
that it is easily extendable to any algorithm.
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?
I understood that the RC2 CEK algorithm was changing from 1.2.840.113549.3.2
to 1.3.6.1.4.1.3029.666.13 (provesional) in the event that the effective key
size and actual key size did not match. This means that if I am doing a
password KEK and an RSA key transport, the value is not well defined
depending on which one I meant to use. If this is not what you meant then
please clarify. My reasoning went as following:
1. CEK key length is obtained from the CEK algorithm description
2. The new algoirthm parameters contain the actualKey lenght and must
therefore be part of the CEK.
3. All other code that uses CMS needs to understand this new CEK algorithm
in the event that a password receipient is included.
Peter.
jim