Subject: Re: A New Triple-DES Key Wrap Algorithm
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Date: Sat, 27 Feb 1999 14:05:35 (NZDT)

>I have a pseudo-random number generator that I am working on for a different
>project.  I put a 0x484848...484848 seed into it and generated the IVs.  Since
>no one has ever looked at that design I will get some new ones from a better
>source.
 
The issue isn't the quality of the numbers, it's a question of verifiability -
the numbers should be from a source which anyone can check, eg hex digits of
pi, e, sqrt( 2 ), whatever.  This is why algorithms like the MDx's and SHA use
well-known, verifiable values.
 
Peter.

Date: Fri, 26 Feb 1999 15:26:27 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Don,  I quite agree.  But regardless of whether we use 
double encryption or OAEP, the masking should completely 
obfuscate any structure that ASN.1 would impose.

Bob

>>> "Don Johnson" <[email-masked]> 02/26/99 12:25PM >>>
Bob, Russ,

ASN.1 is very structured and can be considered to have many known values.
As such, strictly from an info theory viewpoint, use of ASN.1 and
confidentiality are are in opposition.  This does not mean it should be
forbidden, just that we would want to have very strong assurances about the
properties provided by the encryption to use ASN.1 or similar highly
structured formats.

Don Johnson

"Bob Jueneman" <[email-masked]> on 02/26/99 01:38:19 PM

To:   [email-masked] 
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], "Tolga Acar" <[email-masked]>,
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked] (bcc: Don Johnson/Certicom)
Subject:  Re: A New Triple-DES Key Wrap Algorithm

Russ:

You are correct, of course.  The question, then, is whether
we should just go to the OAEP-type wrapping and not have
to worry about changing IV's and how to convey them.
That would be my recommendation.

On a slightly different issue, several times I have strongly urged
that in order to avoid the problem of having N-squared algorithm
IDs for all of the various combinations of CEK and KEK algorithms,
key lengths, and other miscellaneous data, that we first wrap
the CEK in a descriptive ASN.1 structure that describes the
the CEK algorithm/key, and then do the wrapping operation.

However, although I've raised this issue several times and indicated
our strong desire to solve the key wrapping issue once and for all,
you have neither incorporated the idea or argued against it,
so I don't know where you stand.

Obviously anyone who is processing certificates is going to have to
have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures
me that the performance implications would be negligible compared to
almost any encryption operation.

Assuming that is the case, the only reason I could see for not doing
it would be concern about the increase in wrapped key size,
or some lingering not-invented-here bias against ISO/ITU/X.500
mechanisms.  I certainly hope it isn't the later.

Is there anything in the existing protocol that is rigidly sensitive to
the size of the wrapped key?  If so, then that is a problem that
probably ought to be addressed.

If not, then I believe the architectural benefits would far outweigh
any increase in the size of the wrapped key.

Bob

>>> Russ Housley <[email-masked]> 02/26/99 10:51AM >>>
Bob:

You raise an interesting point, but I think it can be easily solved by a
random IV for the first encryption. Of course, this makes the result one
block longer.  And, we would need a different IV for each wrapping.

Russ

At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
>Russ,
>
>There is a possible attack on the double encryption wrap algorithm
>that is a result of the constant IV construction. For that reason, I would
>strongly prefer the OAEP construction. Although it may look complicated
>because there are more steps, the number of line of code is really of no
>consequence at all, but the execution time is important for performance.
>
>Also, I continue to insist that we should not invent n-squared algorithm
>IDs for every possible combination of CEK algorithm and key length
>plus KEK algorithm and key length. Instead, I would _greatly_ prefer to
>first wrap the CEK in a ASN.1 structure that defines the CEK algorithm
>and key length, then whiten that structure with OAEP, encrypt the
resulting
>string with the KEK algorithm, and then provide generic instructions as
>to how to decode the result, either by wrapping the entire wrapped key
>blob in ASN.1 (preferably) or some other way.
>
>Here's the attack on the double-encryption wrapping:
>
>Although most exhaustive search engines divide up the search process
>across multiple machines in order to find a single key as quickly as
possible
>(e.g., the series of RSA challenge ciphers), there is another approach
>based on the use of an associative memory that I wrote up back
>in the '70's but never published.  I call it my "vacuum-cleaner" attack.
>
>Assume for the sake or argument that there are lots and lots of keys
>that have been or will be used to encrypt a known plaintext or
>stereotyped message.  (This is a standard assumption in cryptanalysis.)
>Actually, the attack will succeed with a somewhat weaker condition --
>it isn't necessary to actually know the plaintext -- it is sufficient that
>the plaintext be unvarying.
>
>Let's also assume that each key is used for some interesting purpose --
>sufficiently interesting that it may not be necessary to crack each and
every
>key -- just a few would be useful.  For example, if I were trying to carry
on
>a credit card attack, I don't have to find the key for Bill Gates' or
>Donald Trump's credit card -- just about anyone's will do, and the more
>the merrier.
>
>So for every new key that I have the engine try, I contrive to compare
>the result of encrypting the known plaintext against millions of valid
>ciphertexts that have been intercepted, looking for a match.  Assuming
>an effectively inexhaustible supply of ciphertexts is available, this
attack
>multiplies the effectiveness of the key search engine by an order of a
million
>or more, depending on the size of the associative memory that is
available.
>
>(The use of an associative memory isn't essential -- it was just a
gedanken
>experiment to speed up the comparison process without requiring sorting.)
>
>Two things should be noted.  First, this attack is independent of the KEK
>encryption algorithm used, assuming a fixed block size.  In other words,
>this would apply to single-DES, triple-DES, umpty-DES, 2048-bit RSA,
>or whatever, assuming a constant session key and constant padding.
>
>Second, the attack is also independent of the length or type of session
>key that is used, except that the yield is a Birthday Problem function of
the
>length of the key.  But given a fixed input, i.e., no random whitening or
>changing IV, then two or more matching outputs must imply a matching
>session key.
>
>This leads to a rather surprising result -- even if the KEK performs
double
>encryption using triple-DES (or any other algorithm without whitening)
>to wrap a 40 bit key, two matching session keys can be found with
>approximately 50% probability after only 2^20 or a million or so session
>keys have been generated.
>
>Perhaps more surprisingly, at least to people who haven't been down this
path,
>changing session keys more rapidly may hurt more than it helps -- it just
>exposes that many more keys to attack. Changing the session key often
>in the middle of a session may help limit the ability of the attacker to
>access the entire message, and hence limits the attacker's "take," but it
>increases the chances that a potentially interesting fragment of text
>may be exposed.
>
>I'm sure that someone would observe that sending even a million content
>encryption key encrypted in a constant KEK would be extremely unlikely
>in an S/MIME context, but whether that would really be true would require
>a more subtle, protocol-dependent analysis than I would care to make,
>and in addition I very much want to standardize on one key wrapping
>algorithm that is protocol independent, and not just for S/MIME.
>
>Obviously the above attack can be defeated by prepending some
>additional randomness or by changing the IV. But is also what the OAEP
>approach does, and rather more elegantly.  By the time we have to add
>either a changing IV or some additional randomness (how much would be
>required would have to be decided) the length would probably be close
>to that required for OAEP, which is a much more general solution.
>
>In my mind, at least, some extra bytes in the wrapped key is no big deal,
>but I would like the efficiency to be a good as possible. Triple-DES is
>expensive enough in terms of computational efficiency in software,
>especially in terms of the initial key expansion, and doing it twice
>would be worse yet.
>
>Because the new export regulations permit the use of double the key length
>used for data encryption to be used for key encryption, we are going to be
>using triple-DES in encrypt-decrypt-encrypt mode with only two keys
(A-B-A) for
>key wrapping of all export-grade CEK keys.
>
>This can be optimized by saving the key expansion of the first encryption,
and
>then reusing it for the final encryption.  This technique could
potentially be
>extended to the double encryption wrapping algorithm, by saving the key
>expansion used for all three steps, but in order to do that the
>"double-triple-DES"
>algorithm would probably have to be a single algorithm that is invoked --
>it would be quite difficult to securely save state across two separate
>encryption
>operations.
>
>So my preference, as I said earlier, would be to wrap the CEK in ASN.1,
>whiten with OAEP, and then encrypt using whatever KEK algorithm and
>key length is required, so we don't have to keep re-analyzing this problem
>for every new CEK or KEK algorithm or key length.
>
>If we can define appropriate algorithm IDs, I'm willing and eager to adopt
such
>a standard for  _all_ wrapped keys generated and used within our Novell
>International Cryptographic Infrastructure (NICI), even before S/MIME v3
>progresses to a full standard.  I'd be willing to assign an algorithm OID
>from the
>Novell tree, or we could probably get one from PKCS if there would be any
>problem getting one assigned by the IANA.
>
>Regards,
>
>Bob
>
>
>> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
>All:
>
>Right now, I am leaning toward the double encryption wrap algorithm.  I
>think it will be easy to implement, and it yeilds a shorter result that
the
>OAEP method.  To convince myself that it was easy to implement, I did an
>implementation.  It took me about two hours while watching an old Jimmy
>Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
>routines.  S/MIME v3 will require these algorithms for other capabilities
>besides key wrapping.
>
>If someone else is willing to do an implementation, I would like to
compare
>results.  This will allow a test vector to be included with the algorithm
>description.
>
>Does anyone have any strong objections to the double encryption wrap
>algorithm being selected?
>
>Russ
>
>
>>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>>
>>Key Checksum
>>
>>The CMS Checksum Algorithm is used to provide an content-encryption key
>>integrity check value.  The algorithm is:
>>
>>1.  Compute a 20 octet SHA-1 message digest on the
>>    content-encryption key.
>>2.  Use the most significant (first) eight octets of the
>>    message digest value as the checksum value.
>>
>>Triple-DES Key Wrap
>>
>>1.  Set odd parity for each of the DES key octets comprising
>>    the content-encryption key, call the result CEK.
>>2.  Compute a 8 octet key checksum value on CEK as described above,
>>    call the result ICV.
>>3.  Let CEKICV = CEK || ICV.
>>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>>    an IV of 0xc302e3c1ad8bb738.
>>5.  Reverse the order of the ciphertext octets.  That is, the most
>>    significant (first) octet is swapped with the least significant
>>    (last) octet, and so on.  Call the result TEMP.
>>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use
>>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
>
>Robert R. Jueneman
>Security Architect
>Network Security Development
>Novell, Inc.
>122 East 1700 South
>Provo, UT 84606
>[email-masked] 
>1-801-861-7387

From: "Don Johnson" <[email-masked]>
To: Kevin Kingdon <[email-masked]>
cc: Bob Jueneman <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Tolga Acar <[email-masked]>, [email-masked], [email-masked], Burt Kaliski <[email-masked]>, [email-masked], [email-masked], [email-masked], Ron Rivest <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 26 Feb 1999 16:46:34 -0500
Subject: RE: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Kevin,

Here is what I am saying, I do not think it is not controversial.

1. For any confidentiality method, such as encryption, adding in known
quantities: A) does not keep them confidential, as they are known, and B)
may give an adversary a toehold he would not otherwise have, for example,
with encryption he will know some plaintext and resulting ciphertext (in
the worst case some blocks of known plaintext/ciphertext).

2. For that reason, I resist adding in known data to data that is intended
to be kept confidential.  It is not forbidden to add in known data, I just
want to believe that the cost/benefit tradeoff makes it worthwhile.  And I
try to keep down the amount of known data if possible.

Don Johnson

Kevin Kingdon <[email-masked]> on 02/26/99 02:57:22 PM

To:   Don Johnson/Certicom, Bob Jueneman <[email-masked]>
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], Tolga Acar <[email-masked]>,
      [email-masked], [email-masked], Burt Kaliski
      <[email-masked]>, [email-masked], [email-masked],
      [email-masked], Ron Rivest <[email-masked]>,
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked]
Subject:  RE: A New Triple-DES Key Wrap Algorithm

Don,

Are you saying that the input (plaintext) to an encryption operation must
not be structured? I thought that was what encryption was all about -
hiding
the structure / information content of the plaintext. In any case, doesn't
using OAEP as a part of an encryption scheme mask the plaintext structure
just in case the encryption primitive is vulnerable to attacks that take
advantage of that structure?

Kevin
          -----Original Message-----
          From:     Don Johnson [mailto:[email-masked]]
          Sent:     Friday, February 26, 1999 11:25 AM
          To:  Bob Jueneman
          Cc:  [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Tolga Acar; [email-masked]; [email-masked]; Burt
Kaliski; [email-masked]; [email-masked]; [email-masked]; Ron
Rivest; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
          Subject:  Re: A New Triple-DES Key Wrap Algorithm

          Bob, Russ,

          ASN.1 is very structured and can be considered to have many
known values.
          As such, strictly from an info theory viewpoint, use of
ASN.1 and
          confidentiality are are in opposition.  This does not mean
it should be
          forbidden, just that we would want to have very strong
assurances about the
          properties provided by the encryption to use ASN.1 or
similar highly
          structured formats.

          Don Johnson

          "Bob Jueneman" <[email-masked]> on 02/26/99 01:38:19
PM

          To:   [email-masked]
          cc:   [email-masked], [email-masked],
[email-masked],
                [email-masked], [email-masked], [email-masked],
                [email-masked], [email-masked],
[email-masked],
                [email-masked], [email-masked],
                [email-masked], [email-masked],
                [email-masked],
[email-masked],
                [email-masked], [email-masked],
[email-masked],
                [email-masked], [email-masked],
[email-masked],
                [email-masked], "Tolga Acar"
<[email-masked]>,
                [email-masked], [email-masked],
[email-masked],
                [email-masked], [email-masked],
[email-masked],
                [email-masked], [email-masked],
[email-masked],
                [email-masked], [email-masked],
[email-masked],
                [email-masked] (bcc: Don Johnson/Certicom)
          Subject:  Re: A New Triple-DES Key Wrap Algorithm

          Russ:

          You are correct, of course.  The question, then, is whether
          we should just go to the OAEP-type wrapping and not have
          to worry about changing IV's and how to convey them.
          That would be my recommendation.

          On a slightly different issue, several times I have strongly
urged
          that in order to avoid the problem of having N-squared
algorithm
          IDs for all of the various combinations of CEK and KEK
algorithms,
          key lengths, and other miscellaneous data, that we first
wrap
          the CEK in a descriptive ASN.1 structure that describes the
          the CEK algorithm/key, and then do the wrapping operation.

          However, although I've raised this issue several times and
indicated
          our strong desire to solve the key wrapping issue once and
for all,
          you have neither incorporated the idea or argued against it,
          so I don't know where you stand.

          Obviously anyone who is processing certificates is going to
have to
          have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures
          me that the performance implications would be negligible
compared to
          almost any encryption operation.

          Assuming that is the case, the only reason I could see for
not doing
          it would be concern about the increase in wrapped key size,
          or some lingering not-invented-here bias against
ISO/ITU/X.500
          mechanisms.  I certainly hope it isn't the later.

          Is there anything in the existing protocol that is rigidly
sensitive to
          the size of the wrapped key?  If so, then that is a problem
that
          probably ought to be addressed.

          If not, then I believe the architectural benefits would far
outweigh
          any increase in the size of the wrapped key.

          Bob

          >>> Russ Housley <[email-masked]> 02/26/99 10:51AM >>>
          Bob:

          You raise an interesting point, but I think it can be easily
solved by a
          random IV for the first encryption. Of course, this makes
the result one
          block longer.  And, we would need a different IV for each
wrapping.

          Russ

          At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
          >Russ,
          >
          >There is a possible attack on the double encryption wrap
algorithm
          >that is a result of the constant IV construction. For that
reason, I would
          >strongly prefer the OAEP construction. Although it may look
complicated
          >because there are more steps, the number of line of code is
really of no
          >consequence at all, but the execution time is important for
performance.
          >
          >Also, I continue to insist that we should not invent
n-squared algorithm
          >IDs for every possible combination of CEK algorithm and key
length
          >plus KEK algorithm and key length. Instead, I would
_greatly_ prefer to
          >first wrap the CEK in a ASN.1 structure that defines the
CEK algorithm
          >and key length, then whiten that structure with OAEP,
encrypt the
          resulting
          >string with the KEK algorithm, and then provide generic
instructions as
          >to how to decode the result, either by wrapping the entire
wrapped key
          >blob in ASN.1 (preferably) or some other way.
          >
          >Here's the attack on the double-encryption wrapping:
          >
          >Although most exhaustive search engines divide up the
search process
          >across multiple machines in order to find a single key as
quickly as
          possible
          >(e.g., the series of RSA challenge ciphers), there is
another approach
          >based on the use of an associative memory that I wrote up
back
          >in the '70's but never published.  I call it my
"vacuum-cleaner" attack.
          >
          >Assume for the sake or argument that there are lots and
lots of keys
          >that have been or will be used to encrypt a known plaintext
or
          >stereotyped message.  (This is a standard assumption in
cryptanalysis.)
          >Actually, the attack will succeed with a somewhat weaker
condition --
          >it isn't necessary to actually know the plaintext -- it is
sufficient that
          >the plaintext be unvarying.
          >
          >Let's also assume that each key is used for some
interesting purpose --
          >sufficiently interesting that it may not be necessary to
crack each and
          every
          >key -- just a few would be useful.  For example, if I were
trying to carry
          on
          >a credit card attack, I don't have to find the key for Bill
Gates' or
          >Donald Trump's credit card -- just about anyone's will do,
and the more
          >the merrier.
          >
          >So for every new key that I have the engine try, I contrive
to compare
          >the result of encrypting the known plaintext against
millions of valid
          >ciphertexts that have been intercepted, looking for a
match.  Assuming
          >an effectively inexhaustible supply of ciphertexts is
available, this
          attack
          >multiplies the effectiveness of the key search engine by an
order of a
          million
          >or more, depending on the size of the associative memory
that is
          available.
          >
          >(The use of an associative memory isn't essential -- it was
just a
          gedanken
          >experiment to speed up the comparison process without
requiring sorting.)
          >
          >Two things should be noted.  First, this attack is
independent of the KEK
          >encryption algorithm used, assuming a fixed block size.  In
other words,
          >this would apply to single-DES, triple-DES, umpty-DES,
2048-bit RSA,
          >or whatever, assuming a constant session key and constant
padding.
          >
          >Second, the attack is also independent of the length or
type of session
          >key that is used, except that the yield is a Birthday
Problem function of
          the
          >length of the key.  But given a fixed input, i.e., no
random whitening or
          >changing IV, then two or more matching outputs must imply a
matching
          >session key.
          >
          >This leads to a rather surprising result -- even if the KEK
performs
          double
          >encryption using triple-DES (or any other algorithm without
whitening)
          >to wrap a 40 bit key, two matching session keys can be
found with
          >approximately 50% probability after only 2^20 or a million
or so session
          >keys have been generated.
          >
          >Perhaps more surprisingly, at least to people who haven't
been down this
          path,
          >changing session keys more rapidly may hurt more than it
helps -- it just
          >exposes that many more keys to attack. Changing the session
key often
          >in the middle of a session may help limit the ability of
the attacker to
          >access the entire message, and hence limits the attacker's
"take," but it
          >increases the chances that a potentially interesting
fragment of text
          >may be exposed.
          >
          >I'm sure that someone would observe that sending even a
million content
          >encryption key encrypted in a constant KEK would be
extremely unlikely
          >in an S/MIME context, but whether that would really be true
would require
          >a more subtle, protocol-dependent analysis than I would
care to make,
          >and in addition I very much want to standardize on one key
wrapping
          >algorithm that is protocol independent, and not just for
S/MIME.
          >
          >Obviously the above attack can be defeated by prepending
some
          >additional randomness or by changing the IV. But is also
what the OAEP
          >approach does, and rather more elegantly.  By the time we
have to add
          >either a changing IV or some additional randomness (how
much would be
          >required would have to be decided) the length would
probably be close
          >to that required for OAEP, which is a much more general
solution.
          >
          >In my mind, at least, some extra bytes in the wrapped key
is no big deal,
          >but I would like the efficiency to be a good as possible.
Triple-DES is
          >expensive enough in terms of computational efficiency in
software,
          >especially in terms of the initial key expansion, and doing
it twice
          >would be worse yet.
          >
          >Because the new export regulations permit the use of double
the key length
          >used for data encryption to be used for key encryption, we
are going to be
          >using triple-DES in encrypt-decrypt-encrypt mode with only
two keys
          (A-B-A) for
          >key wrapping of all export-grade CEK keys.
          >
          >This can be optimized by saving the key expansion of the
first encryption,
          and
          >then reusing it for the final encryption.  This technique
could
          potentially be
          >extended to the double encryption wrapping algorithm, by
saving the key
          >expansion used for all three steps, but in order to do that
the
          >"double-triple-DES"
          >algorithm would probably have to be a single algorithm that
is invoked --
          >it would be quite difficult to securely save state across
two separate
          >encryption
          >operations.
          >
          >So my preference, as I said earlier, would be to wrap the
CEK in ASN.1,
          >whiten with OAEP, and then encrypt using whatever KEK
algorithm and
          >key length is required, so we don't have to keep
re-analyzing this problem
          >for every new CEK or KEK algorithm or key length.
          >
          >If we can define appropriate algorithm IDs, I'm willing and
eager to adopt
          such
          >a standard for  _all_ wrapped keys generated and used
within our Novell
          >International Cryptographic Infrastructure (NICI), even
before S/MIME v3
          >progresses to a full standard.  I'd be willing to assign an
algorithm OID
          >from the
          >Novell tree, or we could probably get one from PKCS if
there would be any
          >problem getting one assigned by the IANA.
          >
          >Regards,
          >
          >Bob
          >
          >
          >> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
          >All:
          >
          >Right now, I am leaning toward the double encryption wrap
algorithm.  I
          >think it will be easy to implement, and it yeilds a shorter
result that
          the
          >OAEP method.  To convince myself that it was easy to
implement, I did an
          >implementation.  It took me about two hours while watching
an old Jimmy
          >Stewart movie.  Of course, I already have SHA-1 and
Triple-DES CBC
          >routines.  S/MIME v3 will require these algorithms for
other capabilities
          >besides key wrapping.
          >
          >If someone else is willing to do an implementation, I would
like to
          compare
          >results.  This will allow a test vector to be included with
the algorithm
          >description.
          >
          >Does anyone have any strong objections to the double
encryption wrap
          >algorithm being selected?
          >
          >Russ
          >
          >
          >>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
          >>
          >>Key Checksum
          >>
          >>The CMS Checksum Algorithm is used to provide an
content-encryption key
          >>integrity check value.  The algorithm is:
          >>
          >>1.  Compute a 20 octet SHA-1 message digest on the
          >>    content-encryption key.
          >>2.  Use the most significant (first) eight octets of the
          >>    message digest value as the checksum value.
          >>
          >>Triple-DES Key Wrap
          >>
          >>1.  Set odd parity for each of the DES key octets
comprising
          >>    the content-encryption key, call the result CEK.
          >>2.  Compute a 8 octet key checksum value on CEK as
described above,
          >>    call the result ICV.
          >>3.  Let CEKICV = CEK || ICV.
          >>4.  Encrypt CEKICV in CBC mode using the key-encryption
key.  Use
          >>    an IV of 0xc302e3c1ad8bb738.
          >>5.  Reverse the order of the ciphertext octets.  That is,
the most
          >>    significant (first) octet is swapped with the least
significant
          >>    (last) octet, and so on.  Call the result TEMP.
          >>6.  Encrypt TEMP in CBC mode using the key-encryption key.
Use
          >>    an IV of 0x61a197e5b132e196.  The ciphertext is 32
octets long.
          >
          >Robert R. Jueneman
          >Security Architect
          >Network Security Development
          >Novell, Inc.
          >122 East 1700 South
          >Provo, UT 84606
          >[email-masked]
          >1-801-861-7387

From: Kevin Kingdon <[email-masked]>
To: "'Don Johnson'" <[email-masked]>, Bob Jueneman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Tolga Acar <[email-masked]>, [email-masked], [email-masked], Burt Kaliski <[email-masked]>, [email-masked], [email-masked], [email-masked], Ron Rivest <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: A New Triple-DES Key Wrap Algorithm
Date: Fri, 26 Feb 1999 11:57:22 -0800
Sender: [email-masked]

Don,

Are you saying that the input (plaintext) to an encryption operation must
not be structured? I thought that was what encryption was all about - hiding
the structure / information content of the plaintext. In any case, doesn't
using OAEP as a part of an encryption scheme mask the plaintext structure
just in case the encryption primitive is vulnerable to attacks that take
advantage of that structure?

Kevin
		-----Original Message-----
		From:	Don Johnson [mailto:[email-masked]]
		Sent:	Friday, February 26, 1999 11:25 AM
		To:	Bob Jueneman
		Cc:	[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Tolga Acar; [email-masked]; [email-masked]; Burt
Kaliski; [email-masked]; [email-masked]; [email-masked]; Ron
Rivest; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
		Subject:	Re: A New Triple-DES Key Wrap Algorithm

		Bob, Russ,

		ASN.1 is very structured and can be considered to have many
known values.
		As such, strictly from an info theory viewpoint, use of
ASN.1 and
		confidentiality are are in opposition.  This does not mean
it should be
		forbidden, just that we would want to have very strong
assurances about the
		properties provided by the encryption to use ASN.1 or
similar highly
		structured formats.

		Don Johnson

		"Bob Jueneman" <[email-masked]> on 02/26/99 01:38:19
PM

		To:   [email-masked]
		cc:   [email-masked], [email-masked],
[email-masked],
		      [email-masked], [email-masked], [email-masked],
		      [email-masked], [email-masked],
[email-masked],
		      [email-masked], [email-masked],
		      [email-masked], [email-masked],
		      [email-masked],
[email-masked],
		      [email-masked], [email-masked],
[email-masked],
		      [email-masked], [email-masked],
[email-masked],
		      [email-masked], "Tolga Acar"
<[email-masked]>,
		      [email-masked], [email-masked],
[email-masked],
		      [email-masked], [email-masked],
[email-masked],
		      [email-masked], [email-masked],
[email-masked],
		      [email-masked], [email-masked],
[email-masked],
		      [email-masked] (bcc: Don Johnson/Certicom)
		Subject:  Re: A New Triple-DES Key Wrap Algorithm

		Russ:

		You are correct, of course.  The question, then, is whether
		we should just go to the OAEP-type wrapping and not have
		to worry about changing IV's and how to convey them.
		That would be my recommendation.

		On a slightly different issue, several times I have strongly
urged
		that in order to avoid the problem of having N-squared
algorithm
		IDs for all of the various combinations of CEK and KEK
algorithms,
		key lengths, and other miscellaneous data, that we first
wrap
		the CEK in a descriptive ASN.1 structure that describes the
		the CEK algorithm/key, and then do the wrapping operation.

		However, although I've raised this issue several times and
indicated
		our strong desire to solve the key wrapping issue once and
for all,
		you have neither incorporated the idea or argued against it,
		so I don't know where you stand.

		Obviously anyone who is processing certificates is going to
have to
		have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures
		me that the performance implications would be negligible
compared to
		almost any encryption operation.

		Assuming that is the case, the only reason I could see for
not doing
		it would be concern about the increase in wrapped key size,
		or some lingering not-invented-here bias against
ISO/ITU/X.500
		mechanisms.  I certainly hope it isn't the later.

		Is there anything in the existing protocol that is rigidly
sensitive to
		the size of the wrapped key?  If so, then that is a problem
that
		probably ought to be addressed.

		If not, then I believe the architectural benefits would far
outweigh
		any increase in the size of the wrapped key.

		Bob

		>>> Russ Housley <[email-masked]> 02/26/99 10:51AM >>>
		Bob:

		You raise an interesting point, but I think it can be easily
solved by a
		random IV for the first encryption. Of course, this makes
the result one
		block longer.  And, we would need a different IV for each
wrapping.

		Russ

		At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
		>Russ,
		>
		>There is a possible attack on the double encryption wrap
algorithm
		>that is a result of the constant IV construction. For that
reason, I would
		>strongly prefer the OAEP construction. Although it may look
complicated
		>because there are more steps, the number of line of code is
really of no
		>consequence at all, but the execution time is important for
performance.
		>
		>Also, I continue to insist that we should not invent
n-squared algorithm
		>IDs for every possible combination of CEK algorithm and key
length
		>plus KEK algorithm and key length. Instead, I would
_greatly_ prefer to
		>first wrap the CEK in a ASN.1 structure that defines the
CEK algorithm
		>and key length, then whiten that structure with OAEP,
encrypt the
		resulting
		>string with the KEK algorithm, and then provide generic
instructions as
		>to how to decode the result, either by wrapping the entire
wrapped key
		>blob in ASN.1 (preferably) or some other way.
		>
		>Here's the attack on the double-encryption wrapping:
		>
		>Although most exhaustive search engines divide up the
search process
		>across multiple machines in order to find a single key as
quickly as
		possible
		>(e.g., the series of RSA challenge ciphers), there is
another approach
		>based on the use of an associative memory that I wrote up
back
		>in the '70's but never published.  I call it my
"vacuum-cleaner" attack.
		>
		>Assume for the sake or argument that there are lots and
lots of keys
		>that have been or will be used to encrypt a known plaintext
or
		>stereotyped message.  (This is a standard assumption in
cryptanalysis.)
		>Actually, the attack will succeed with a somewhat weaker
condition --
		>it isn't necessary to actually know the plaintext -- it is
sufficient that
		>the plaintext be unvarying.
		>
		>Let's also assume that each key is used for some
interesting purpose --
		>sufficiently interesting that it may not be necessary to
crack each and
		every
		>key -- just a few would be useful.  For example, if I were
trying to carry
		on
		>a credit card attack, I don't have to find the key for Bill
Gates' or
		>Donald Trump's credit card -- just about anyone's will do,
and the more
		>the merrier.
		>
		>So for every new key that I have the engine try, I contrive
to compare
		>the result of encrypting the known plaintext against
millions of valid
		>ciphertexts that have been intercepted, looking for a
match.  Assuming
		>an effectively inexhaustible supply of ciphertexts is
available, this
		attack
		>multiplies the effectiveness of the key search engine by an
order of a
		million
		>or more, depending on the size of the associative memory
that is
		available.
		>
		>(The use of an associative memory isn't essential -- it was
just a
		gedanken
		>experiment to speed up the comparison process without
requiring sorting.)
		>
		>Two things should be noted.  First, this attack is
independent of the KEK
		>encryption algorithm used, assuming a fixed block size.  In
other words,
		>this would apply to single-DES, triple-DES, umpty-DES,
2048-bit RSA,
		>or whatever, assuming a constant session key and constant
padding.
		>
		>Second, the attack is also independent of the length or
type of session
		>key that is used, except that the yield is a Birthday
Problem function of
		the
		>length of the key.  But given a fixed input, i.e., no
random whitening or
		>changing IV, then two or more matching outputs must imply a
matching
		>session key.
		>
		>This leads to a rather surprising result -- even if the KEK
performs
		double
		>encryption using triple-DES (or any other algorithm without
whitening)
		>to wrap a 40 bit key, two matching session keys can be
found with
		>approximately 50% probability after only 2^20 or a million
or so session
		>keys have been generated.
		>
		>Perhaps more surprisingly, at least to people who haven't
been down this
		path,
		>changing session keys more rapidly may hurt more than it
helps -- it just
		>exposes that many more keys to attack. Changing the session
key often
		>in the middle of a session may help limit the ability of
the attacker to
		>access the entire message, and hence limits the attacker's
"take," but it
		>increases the chances that a potentially interesting
fragment of text
		>may be exposed.
		>
		>I'm sure that someone would observe that sending even a
million content
		>encryption key encrypted in a constant KEK would be
extremely unlikely
		>in an S/MIME context, but whether that would really be true
would require
		>a more subtle, protocol-dependent analysis than I would
care to make,
		>and in addition I very much want to standardize on one key
wrapping
		>algorithm that is protocol independent, and not just for
S/MIME.
		>
		>Obviously the above attack can be defeated by prepending
some
		>additional randomness or by changing the IV. But is also
what the OAEP
		>approach does, and rather more elegantly.  By the time we
have to add
		>either a changing IV or some additional randomness (how
much would be
		>required would have to be decided) the length would
probably be close
		>to that required for OAEP, which is a much more general
solution.
		>
		>In my mind, at least, some extra bytes in the wrapped key
is no big deal,
		>but I would like the efficiency to be a good as possible.
Triple-DES is
		>expensive enough in terms of computational efficiency in
software,
		>especially in terms of the initial key expansion, and doing
it twice
		>would be worse yet.
		>
		>Because the new export regulations permit the use of double
the key length
		>used for data encryption to be used for key encryption, we
are going to be
		>using triple-DES in encrypt-decrypt-encrypt mode with only
two keys
		(A-B-A) for
		>key wrapping of all export-grade CEK keys.
		>
		>This can be optimized by saving the key expansion of the
first encryption,
		and
		>then reusing it for the final encryption.  This technique
could
		potentially be
		>extended to the double encryption wrapping algorithm, by
saving the key
		>expansion used for all three steps, but in order to do that
the
		>"double-triple-DES"
		>algorithm would probably have to be a single algorithm that
is invoked --
		>it would be quite difficult to securely save state across
two separate
		>encryption
		>operations.
		>
		>So my preference, as I said earlier, would be to wrap the
CEK in ASN.1,
		>whiten with OAEP, and then encrypt using whatever KEK
algorithm and
		>key length is required, so we don't have to keep
re-analyzing this problem
		>for every new CEK or KEK algorithm or key length.
		>
		>If we can define appropriate algorithm IDs, I'm willing and
eager to adopt
		such
		>a standard for  _all_ wrapped keys generated and used
within our Novell
		>International Cryptographic Infrastructure (NICI), even
before S/MIME v3
		>progresses to a full standard.  I'd be willing to assign an
algorithm OID
		>from the
		>Novell tree, or we could probably get one from PKCS if
there would be any
		>problem getting one assigned by the IANA.
		>
		>Regards,
		>
		>Bob
		>
		>
		>> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
		>All:
		>
		>Right now, I am leaning toward the double encryption wrap
algorithm.  I
		>think it will be easy to implement, and it yeilds a shorter
result that
		the
		>OAEP method.  To convince myself that it was easy to
implement, I did an
		>implementation.  It took me about two hours while watching
an old Jimmy
		>Stewart movie.  Of course, I already have SHA-1 and
Triple-DES CBC
		>routines.  S/MIME v3 will require these algorithms for
other capabilities
		>besides key wrapping.
		>
		>If someone else is willing to do an implementation, I would
like to
		compare
		>results.  This will allow a test vector to be included with
the algorithm
		>description.
		>
		>Does anyone have any strong objections to the double
encryption wrap
		>algorithm being selected?
		>
		>Russ
		>
		>
		>>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
		>>
		>>Key Checksum
		>>
		>>The CMS Checksum Algorithm is used to provide an
content-encryption key
		>>integrity check value.  The algorithm is:
		>>
		>>1.  Compute a 20 octet SHA-1 message digest on the
		>>    content-encryption key.
		>>2.  Use the most significant (first) eight octets of the
		>>    message digest value as the checksum value.
		>>
		>>Triple-DES Key Wrap
		>>
		>>1.  Set odd parity for each of the DES key octets
comprising
		>>    the content-encryption key, call the result CEK.
		>>2.  Compute a 8 octet key checksum value on CEK as
described above,
		>>    call the result ICV.
		>>3.  Let CEKICV = CEK || ICV.
		>>4.  Encrypt CEKICV in CBC mode using the key-encryption
key.  Use
		>>    an IV of 0xc302e3c1ad8bb738.
		>>5.  Reverse the order of the ciphertext octets.  That is,
the most
		>>    significant (first) octet is swapped with the least
significant
		>>    (last) octet, and so on.  Call the result TEMP.
		>>6.  Encrypt TEMP in CBC mode using the key-encryption key.
Use
		>>    an IV of 0x61a197e5b132e196.  The ciphertext is 32
octets long.
		>
		>Robert R. Jueneman
		>Security Architect
		>Network Security Development
		>Novell, Inc.
		>122 East 1700 South
		>Provo, UT 84606
		>[email-masked]
		>1-801-861-7387

		

From: "Don Johnson" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "Tolga Acar" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 26 Feb 1999 14:25:13 -0500
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Bob, Russ,

ASN.1 is very structured and can be considered to have many known values.
As such, strictly from an info theory viewpoint, use of ASN.1 and
confidentiality are are in opposition.  This does not mean it should be
forbidden, just that we would want to have very strong assurances about the
properties provided by the encryption to use ASN.1 or similar highly
structured formats.

Don Johnson

"Bob Jueneman" <[email-masked]> on 02/26/99 01:38:19 PM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], "Tolga Acar" <[email-masked]>,
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked] (bcc: Don Johnson/Certicom)
Subject:  Re: A New Triple-DES Key Wrap Algorithm

Russ:

You are correct, of course.  The question, then, is whether
we should just go to the OAEP-type wrapping and not have
to worry about changing IV's and how to convey them.
That would be my recommendation.

On a slightly different issue, several times I have strongly urged
that in order to avoid the problem of having N-squared algorithm
IDs for all of the various combinations of CEK and KEK algorithms,
key lengths, and other miscellaneous data, that we first wrap
the CEK in a descriptive ASN.1 structure that describes the
the CEK algorithm/key, and then do the wrapping operation.

However, although I've raised this issue several times and indicated
our strong desire to solve the key wrapping issue once and for all,
you have neither incorporated the idea or argued against it,
so I don't know where you stand.

Obviously anyone who is processing certificates is going to have to
have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures
me that the performance implications would be negligible compared to
almost any encryption operation.

Assuming that is the case, the only reason I could see for not doing
it would be concern about the increase in wrapped key size,
or some lingering not-invented-here bias against ISO/ITU/X.500
mechanisms.  I certainly hope it isn't the later.

Is there anything in the existing protocol that is rigidly sensitive to
the size of the wrapped key?  If so, then that is a problem that
probably ought to be addressed.

If not, then I believe the architectural benefits would far outweigh
any increase in the size of the wrapped key.

Bob

>>> Russ Housley <[email-masked]> 02/26/99 10:51AM >>>
Bob:

You raise an interesting point, but I think it can be easily solved by a
random IV for the first encryption. Of course, this makes the result one
block longer.  And, we would need a different IV for each wrapping.

Russ

At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
>Russ,
>
>There is a possible attack on the double encryption wrap algorithm
>that is a result of the constant IV construction. For that reason, I would
>strongly prefer the OAEP construction. Although it may look complicated
>because there are more steps, the number of line of code is really of no
>consequence at all, but the execution time is important for performance.
>
>Also, I continue to insist that we should not invent n-squared algorithm
>IDs for every possible combination of CEK algorithm and key length
>plus KEK algorithm and key length. Instead, I would _greatly_ prefer to
>first wrap the CEK in a ASN.1 structure that defines the CEK algorithm
>and key length, then whiten that structure with OAEP, encrypt the
resulting
>string with the KEK algorithm, and then provide generic instructions as
>to how to decode the result, either by wrapping the entire wrapped key
>blob in ASN.1 (preferably) or some other way.
>
>Here's the attack on the double-encryption wrapping:
>
>Although most exhaustive search engines divide up the search process
>across multiple machines in order to find a single key as quickly as
possible
>(e.g., the series of RSA challenge ciphers), there is another approach
>based on the use of an associative memory that I wrote up back
>in the '70's but never published.  I call it my "vacuum-cleaner" attack.
>
>Assume for the sake or argument that there are lots and lots of keys
>that have been or will be used to encrypt a known plaintext or
>stereotyped message.  (This is a standard assumption in cryptanalysis.)
>Actually, the attack will succeed with a somewhat weaker condition --
>it isn't necessary to actually know the plaintext -- it is sufficient that
>the plaintext be unvarying.
>
>Let's also assume that each key is used for some interesting purpose --
>sufficiently interesting that it may not be necessary to crack each and
every
>key -- just a few would be useful.  For example, if I were trying to carry
on
>a credit card attack, I don't have to find the key for Bill Gates' or
>Donald Trump's credit card -- just about anyone's will do, and the more
>the merrier.
>
>So for every new key that I have the engine try, I contrive to compare
>the result of encrypting the known plaintext against millions of valid
>ciphertexts that have been intercepted, looking for a match.  Assuming
>an effectively inexhaustible supply of ciphertexts is available, this
attack
>multiplies the effectiveness of the key search engine by an order of a
million
>or more, depending on the size of the associative memory that is
available.
>
>(The use of an associative memory isn't essential -- it was just a
gedanken
>experiment to speed up the comparison process without requiring sorting.)
>
>Two things should be noted.  First, this attack is independent of the KEK
>encryption algorithm used, assuming a fixed block size.  In other words,
>this would apply to single-DES, triple-DES, umpty-DES, 2048-bit RSA,
>or whatever, assuming a constant session key and constant padding.
>
>Second, the attack is also independent of the length or type of session
>key that is used, except that the yield is a Birthday Problem function of
the
>length of the key.  But given a fixed input, i.e., no random whitening or
>changing IV, then two or more matching outputs must imply a matching
>session key.
>
>This leads to a rather surprising result -- even if the KEK performs
double
>encryption using triple-DES (or any other algorithm without whitening)
>to wrap a 40 bit key, two matching session keys can be found with
>approximately 50% probability after only 2^20 or a million or so session
>keys have been generated.
>
>Perhaps more surprisingly, at least to people who haven't been down this
path,
>changing session keys more rapidly may hurt more than it helps -- it just
>exposes that many more keys to attack. Changing the session key often
>in the middle of a session may help limit the ability of the attacker to
>access the entire message, and hence limits the attacker's "take," but it
>increases the chances that a potentially interesting fragment of text
>may be exposed.
>
>I'm sure that someone would observe that sending even a million content
>encryption key encrypted in a constant KEK would be extremely unlikely
>in an S/MIME context, but whether that would really be true would require
>a more subtle, protocol-dependent analysis than I would care to make,
>and in addition I very much want to standardize on one key wrapping
>algorithm that is protocol independent, and not just for S/MIME.
>
>Obviously the above attack can be defeated by prepending some
>additional randomness or by changing the IV. But is also what the OAEP
>approach does, and rather more elegantly.  By the time we have to add
>either a changing IV or some additional randomness (how much would be
>required would have to be decided) the length would probably be close
>to that required for OAEP, which is a much more general solution.
>
>In my mind, at least, some extra bytes in the wrapped key is no big deal,
>but I would like the efficiency to be a good as possible. Triple-DES is
>expensive enough in terms of computational efficiency in software,
>especially in terms of the initial key expansion, and doing it twice
>would be worse yet.
>
>Because the new export regulations permit the use of double the key length
>used for data encryption to be used for key encryption, we are going to be
>using triple-DES in encrypt-decrypt-encrypt mode with only two keys
(A-B-A) for
>key wrapping of all export-grade CEK keys.
>
>This can be optimized by saving the key expansion of the first encryption,
and
>then reusing it for the final encryption.  This technique could
potentially be
>extended to the double encryption wrapping algorithm, by saving the key
>expansion used for all three steps, but in order to do that the
>"double-triple-DES"
>algorithm would probably have to be a single algorithm that is invoked --
>it would be quite difficult to securely save state across two separate
>encryption
>operations.
>
>So my preference, as I said earlier, would be to wrap the CEK in ASN.1,
>whiten with OAEP, and then encrypt using whatever KEK algorithm and
>key length is required, so we don't have to keep re-analyzing this problem
>for every new CEK or KEK algorithm or key length.
>
>If we can define appropriate algorithm IDs, I'm willing and eager to adopt
such
>a standard for  _all_ wrapped keys generated and used within our Novell
>International Cryptographic Infrastructure (NICI), even before S/MIME v3
>progresses to a full standard.  I'd be willing to assign an algorithm OID
>from the
>Novell tree, or we could probably get one from PKCS if there would be any
>problem getting one assigned by the IANA.
>
>Regards,
>
>Bob
>
>
>> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
>All:
>
>Right now, I am leaning toward the double encryption wrap algorithm.  I
>think it will be easy to implement, and it yeilds a shorter result that
the
>OAEP method.  To convince myself that it was easy to implement, I did an
>implementation.  It took me about two hours while watching an old Jimmy
>Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
>routines.  S/MIME v3 will require these algorithms for other capabilities
>besides key wrapping.
>
>If someone else is willing to do an implementation, I would like to
compare
>results.  This will allow a test vector to be included with the algorithm
>description.
>
>Does anyone have any strong objections to the double encryption wrap
>algorithm being selected?
>
>Russ
>
>
>>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>>
>>Key Checksum
>>
>>The CMS Checksum Algorithm is used to provide an content-encryption key
>>integrity check value.  The algorithm is:
>>
>>1.  Compute a 20 octet SHA-1 message digest on the
>>    content-encryption key.
>>2.  Use the most significant (first) eight octets of the
>>    message digest value as the checksum value.
>>
>>Triple-DES Key Wrap
>>
>>1.  Set odd parity for each of the DES key octets comprising
>>    the content-encryption key, call the result CEK.
>>2.  Compute a 8 octet key checksum value on CEK as described above,
>>    call the result ICV.
>>3.  Let CEKICV = CEK || ICV.
>>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>>    an IV of 0xc302e3c1ad8bb738.
>>5.  Reverse the order of the ciphertext octets.  That is, the most
>>    significant (first) octet is swapped with the least significant
>>    (last) octet, and so on.  Call the result TEMP.
>>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use
>>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
>
>Robert R. Jueneman
>Security Architect
>Network Security Development
>Novell, Inc.
>122 East 1700 South
>Provo, UT 84606
>[email-masked]
>1-801-861-7387

From: "Don Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "Tolga Acar" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 26 Feb 1999 14:19:35 -0500
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ,

Using a random IV for each encryption helps ensure that each block is
encrypted with the same strength, so my previous concerns about weaknesses
at the ends goes away.

Don Johnson

Russ Housley <[email-masked]> on 02/26/99 12:51:44 PM

To:   "Bob Jueneman" <[email-masked]>
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked], "Tolga Acar"
      <[email-masked]>, [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked] (bcc: Don Johnson/Certicom)
Subject:  Re: A New Triple-DES Key Wrap Algorithm

Bob:

You raise an interesting point, but I think it can be easily solved by a
random IV for the first encryption. Of course, this makes the result one
block longer.  And, we would need a different IV for each wrapping.

Russ

At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
>Russ,
>
>There is a possible attack on the double encryption wrap algorithm
>that is a result of the constant IV construction. For that reason, I would
>strongly prefer the OAEP construction. Although it may look complicated
>because there are more steps, the number of line of code is really of no
>consequence at all, but the execution time is important for performance.
>
>Also, I continue to insist that we should not invent n-squared algorithm
>IDs for every possible combination of CEK algorithm and key length
>plus KEK algorithm and key length. Instead, I would _greatly_ prefer to
>first wrap the CEK in a ASN.1 structure that defines the CEK algorithm
>and key length, then whiten that structure with OAEP, encrypt the
resulting
>string with the KEK algorithm, and then provide generic instructions as
>to how to decode the result, either by wrapping the entire wrapped key
>blob in ASN.1 (preferably) or some other way.
>
>Here's the attack on the double-encryption wrapping:
>
>Although most exhaustive search engines divide up the search process
>across multiple machines in order to find a single key as quickly as
possible
>(e.g., the series of RSA challenge ciphers), there is another approach
>based on the use of an associative memory that I wrote up back
>in the '70's but never published.  I call it my "vacuum-cleaner" attack.
>
>Assume for the sake or argument that there are lots and lots of keys
>that have been or will be used to encrypt a known plaintext or
>stereotyped message.  (This is a standard assumption in cryptanalysis.)
>Actually, the attack will succeed with a somewhat weaker condition --
>it isn't necessary to actually know the plaintext -- it is sufficient that
>the plaintext be unvarying.
>
>Let's also assume that each key is used for some interesting purpose --
>sufficiently interesting that it may not be necessary to crack each and
every
>key -- just a few would be useful.  For example, if I were trying to carry
on
>a credit card attack, I don't have to find the key for Bill Gates' or
>Donald Trump's credit card -- just about anyone's will do, and the more
>the merrier.
>
>So for every new key that I have the engine try, I contrive to compare
>the result of encrypting the known plaintext against millions of valid
>ciphertexts that have been intercepted, looking for a match.  Assuming
>an effectively inexhaustible supply of ciphertexts is available, this
attack
>multiplies the effectiveness of the key search engine by an order of a
million
>or more, depending on the size of the associative memory that is
available.
>
>(The use of an associative memory isn't essential -- it was just a
gedanken
>experiment to speed up the comparison process without requiring sorting.)
>
>Two things should be noted.  First, this attack is independent of the KEK
>encryption algorithm used, assuming a fixed block size.  In other words,
>this would apply to single-DES, triple-DES, umpty-DES, 2048-bit RSA,
>or whatever, assuming a constant session key and constant padding.
>
>Second, the attack is also independent of the length or type of session
>key that is used, except that the yield is a Birthday Problem function of
the
>length of the key.  But given a fixed input, i.e., no random whitening or
>changing IV, then two or more matching outputs must imply a matching
>session key.
>
>This leads to a rather surprising result -- even if the KEK performs
double
>encryption using triple-DES (or any other algorithm without whitening)
>to wrap a 40 bit key, two matching session keys can be found with
>approximately 50% probability after only 2^20 or a million or so session
>keys have been generated.
>
>Perhaps more surprisingly, at least to people who haven't been down this
path,
>changing session keys more rapidly may hurt more than it helps -- it just
>exposes that many more keys to attack. Changing the session key often
>in the middle of a session may help limit the ability of the attacker to
>access the entire message, and hence limits the attacker's "take," but it
>increases the chances that a potentially interesting fragment of text
>may be exposed.
>
>I'm sure that someone would observe that sending even a million content
>encryption key encrypted in a constant KEK would be extremely unlikely
>in an S/MIME context, but whether that would really be true would require
>a more subtle, protocol-dependent analysis than I would care to make,
>and in addition I very much want to standardize on one key wrapping
>algorithm that is protocol independent, and not just for S/MIME.
>
>Obviously the above attack can be defeated by prepending some
>additional randomness or by changing the IV. But is also what the OAEP
>approach does, and rather more elegantly.  By the time we have to add
>either a changing IV or some additional randomness (how much would be
>required would have to be decided) the length would probably be close
>to that required for OAEP, which is a much more general solution.
>
>In my mind, at least, some extra bytes in the wrapped key is no big deal,
>but I would like the efficiency to be a good as possible. Triple-DES is
>expensive enough in terms of computational efficiency in software,
>especially in terms of the initial key expansion, and doing it twice
>would be worse yet.
>
>Because the new export regulations permit the use of double the key length
>used for data encryption to be used for key encryption, we are going to be
>using triple-DES in encrypt-decrypt-encrypt mode with only two keys
(A-B-A) for
>key wrapping of all export-grade CEK keys.
>
>This can be optimized by saving the key expansion of the first encryption,
and
>then reusing it for the final encryption.  This technique could
potentially be
>extended to the double encryption wrapping algorithm, by saving the key
>expansion used for all three steps, but in order to do that the
>"double-triple-DES"
>algorithm would probably have to be a single algorithm that is invoked --
>it would be quite difficult to securely save state across two separate
>encryption
>operations.
>
>So my preference, as I said earlier, would be to wrap the CEK in ASN.1,
>whiten with OAEP, and then encrypt using whatever KEK algorithm and
>key length is required, so we don't have to keep re-analyzing this problem
>for every new CEK or KEK algorithm or key length.
>
>If we can define appropriate algorithm IDs, I'm willing and eager to adopt
such
>a standard for  _all_ wrapped keys generated and used within our Novell
>International Cryptographic Infrastructure (NICI), even before S/MIME v3
>progresses to a full standard.  I'd be willing to assign an algorithm OID
>from the
>Novell tree, or we could probably get one from PKCS if there would be any
>problem getting one assigned by the IANA.
>
>Regards,
>
>Bob
>
>
>> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
>All:
>
>Right now, I am leaning toward the double encryption wrap algorithm.  I
>think it will be easy to implement, and it yeilds a shorter result that
the
>OAEP method.  To convince myself that it was easy to implement, I did an
>implementation.  It took me about two hours while watching an old Jimmy
>Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
>routines.  S/MIME v3 will require these algorithms for other capabilities
>besides key wrapping.
>
>If someone else is willing to do an implementation, I would like to
compare
>results.  This will allow a test vector to be included with the algorithm
>description.
>
>Does anyone have any strong objections to the double encryption wrap
>algorithm being selected?
>
>Russ
>
>
>>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>>
>>Key Checksum
>>
>>The CMS Checksum Algorithm is used to provide an content-encryption key
>>integrity check value.  The algorithm is:
>>
>>1.  Compute a 20 octet SHA-1 message digest on the
>>    content-encryption key.
>>2.  Use the most significant (first) eight octets of the
>>    message digest value as the checksum value.
>>
>>Triple-DES Key Wrap
>>
>>1.  Set odd parity for each of the DES key octets comprising
>>    the content-encryption key, call the result CEK.
>>2.  Compute a 8 octet key checksum value on CEK as described above,
>>    call the result ICV.
>>3.  Let CEKICV = CEK || ICV.
>>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>>    an IV of 0xc302e3c1ad8bb738.
>>5.  Reverse the order of the ciphertext octets.  That is, the most
>>    significant (first) octet is swapped with the least significant
>>    (last) octet, and so on.  Call the result TEMP.
>>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use
>>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
>
>Robert R. Jueneman
>Security Architect
>Network Security Development
>Novell, Inc.
>122 East 1700 South
>Provo, UT 84606
>[email-masked]
>1-801-861-7387

From: Paul Van Oorschot <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Tolga Acar <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: A New Triple-DES Key Wrap Algorithm
Date: Fri, 26 Feb 1999 13:43:43 -0500
Sender: [email-masked]

Russ - if at all possible, please use a standard technique (e.g. OAEP per
one of the emerging standards) rather than inventing a new customized
scheme.  

Paul.

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]]
> Sent: 	Friday, February 26, 1999 1:38 PM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; Tolga Acar;
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: 	Re: A New Triple-DES Key Wrap Algorithm
> 
> Russ:
> 
> You are correct, of course.  The question, then, is whether
> we should just go to the OAEP-type wrapping and not have
> to worry about changing IV's and how to convey them.
> That would be my recommendation.
> 
> On a slightly different issue, several times I have strongly urged
> that in order to avoid the problem of having N-squared algorithm
> IDs for all of the various combinations of CEK and KEK algorithms,
> key lengths, and other miscellaneous data, that we first wrap
> the CEK in a descriptive ASN.1 structure that describes the 
> the CEK algorithm/key, and then do the wrapping operation.
> 
> However, although I've raised this issue several times and indicated
> our strong desire to solve the key wrapping issue once and for all,
> you have neither incorporated the idea or argued against it,
> so I don't know where you stand.
> 
> Obviously anyone who is processing certificates is going to have to 
> have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures 
> me that the performance implications would be negligible compared to
> almost any encryption operation.
> 
> Assuming that is the case, the only reason I could see for not doing 
> it would be concern about the increase in wrapped key size,
> or some lingering not-invented-here bias against ISO/ITU/X.500
> mechanisms.  I certainly hope it isn't the later.
> 
> Is there anything in the existing protocol that is rigidly sensitive to 
> the size of the wrapped key?  If so, then that is a problem that 
> probably ought to be addressed.
> 
> If not, then I believe the architectural benefits would far outweigh
> any increase in the size of the wrapped key.
> 
> Bob
> 
> >>> Russ Housley <[email-masked]> 02/26/99 10:51AM >>>
> Bob:
> 
> You raise an interesting point, but I think it can be easily solved by a
> random IV for the first encryption. Of course, this makes the result one
> block longer.  And, we would need a different IV for each wrapping.
> 
> Russ
> 
> 
> At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
> >Russ,
> >
> >There is a possible attack on the double encryption wrap algorithm 
> >that is a result of the constant IV construction. For that reason, I
> would
> >strongly prefer the OAEP construction. Although it may look complicated
> >because there are more steps, the number of line of code is really of no 
> >consequence at all, but the execution time is important for performance.
> >
> >Also, I continue to insist that we should not invent n-squared algorithm 
> >IDs for every possible combination of CEK algorithm and key length
> >plus KEK algorithm and key length. Instead, I would _greatly_ prefer to 
> >first wrap the CEK in a ASN.1 structure that defines the CEK algorithm 
> >and key length, then whiten that structure with OAEP, encrypt the
> resulting
> >string with the KEK algorithm, and then provide generic instructions as
> >to how to decode the result, either by wrapping the entire wrapped key 
> >blob in ASN.1 (preferably) or some other way.
> >
> >Here's the attack on the double-encryption wrapping:
> >
> >Although most exhaustive search engines divide up the search process
> >across multiple machines in order to find a single key as quickly as
> possible
> >(e.g., the series of RSA challenge ciphers), there is another approach
> >based on the use of an associative memory that I wrote up back
> >in the '70's but never published.  I call it my "vacuum-cleaner" attack.
> >
> >Assume for the sake or argument that there are lots and lots of keys
> >that have been or will be used to encrypt a known plaintext or 
> >stereotyped message.  (This is a standard assumption in cryptanalysis.) 
> >Actually, the attack will succeed with a somewhat weaker condition --
> >it isn't necessary to actually know the plaintext -- it is sufficient
> that
> >the plaintext be unvarying.
> >
> >Let's also assume that each key is used for some interesting purpose --
> >sufficiently interesting that it may not be necessary to crack each and
> every
> >key -- just a few would be useful.  For example, if I were trying to
> carry on 
> >a credit card attack, I don't have to find the key for Bill Gates' or 
> >Donald Trump's credit card -- just about anyone's will do, and the more 
> >the merrier.
> >
> >So for every new key that I have the engine try, I contrive to compare 
> >the result of encrypting the known plaintext against millions of valid 
> >ciphertexts that have been intercepted, looking for a match.  Assuming 
> >an effectively inexhaustible supply of ciphertexts is available, this
> attack 
> >multiplies the effectiveness of the key search engine by an order of a
> million
> >or more, depending on the size of the associative memory that is
> available.
> >
> >(The use of an associative memory isn't essential -- it was just a
> gedanken
> >experiment to speed up the comparison process without requiring sorting.)
> >
> >Two things should be noted.  First, this attack is independent of the KEK
> 
> >encryption algorithm used, assuming a fixed block size.  In other words, 
> >this would apply to single-DES, triple-DES, umpty-DES, 2048-bit RSA,
> >or whatever, assuming a constant session key and constant padding.
> >
> >Second, the attack is also independent of the length or type of session 
> >key that is used, except that the yield is a Birthday Problem function of
> the
> >length of the key.  But given a fixed input, i.e., no random whitening or
> 
> >changing IV, then two or more matching outputs must imply a matching
> >session key.  
> >
> >This leads to a rather surprising result -- even if the KEK performs
> double 
> >encryption using triple-DES (or any other algorithm without whitening)
> >to wrap a 40 bit key, two matching session keys can be found with 
> >approximately 50% probability after only 2^20 or a million or so session 
> >keys have been generated.
> >
> >Perhaps more surprisingly, at least to people who haven't been down this
> path,
> >changing session keys more rapidly may hurt more than it helps -- it just
> 
> >exposes that many more keys to attack. Changing the session key often 
> >in the middle of a session may help limit the ability of the attacker to 
> >access the entire message, and hence limits the attacker's "take," but it
> 
> >increases the chances that a potentially interesting fragment of text 
> >may be exposed.
> >
> >I'm sure that someone would observe that sending even a million content 
> >encryption key encrypted in a constant KEK would be extremely unlikely
> >in an S/MIME context, but whether that would really be true would require
> >a more subtle, protocol-dependent analysis than I would care to make,
> >and in addition I very much want to standardize on one key wrapping 
> >algorithm that is protocol independent, and not just for S/MIME.
> >
> >Obviously the above attack can be defeated by prepending some 
> >additional randomness or by changing the IV. But is also what the OAEP
> >approach does, and rather more elegantly.  By the time we have to add
> >either a changing IV or some additional randomness (how much would be
> >required would have to be decided) the length would probably be close
> >to that required for OAEP, which is a much more general solution.
> >
> >In my mind, at least, some extra bytes in the wrapped key is no big deal,
> >but I would like the efficiency to be a good as possible. Triple-DES is 
> >expensive enough in terms of computational efficiency in software, 
> >especially in terms of the initial key expansion, and doing it twice 
> >would be worse yet.
> >
> >Because the new export regulations permit the use of double the key
> length 
> >used for data encryption to be used for key encryption, we are going to
> be
> >using triple-DES in encrypt-decrypt-encrypt mode with only two keys
> (A-B-A) for
> >key wrapping of all export-grade CEK keys.
> >
> >This can be optimized by saving the key expansion of the first
> encryption,
> and 
> >then reusing it for the final encryption.  This technique could
> potentially be 
> >extended to the double encryption wrapping algorithm, by saving the key  
> >expansion used for all three steps, but in order to do that the 
> >"double-triple-DES"
> >algorithm would probably have to be a single algorithm that is invoked --
> >it would be quite difficult to securely save state across two separate 
> >encryption
> >operations.
> >
> >So my preference, as I said earlier, would be to wrap the CEK in ASN.1, 
> >whiten with OAEP, and then encrypt using whatever KEK algorithm and 
> >key length is required, so we don't have to keep re-analyzing this
> problem 
> >for every new CEK or KEK algorithm or key length.
> >
> >If we can define appropriate algorithm IDs, I'm willing and eager to
> adopt
> such
> >a standard for  _all_ wrapped keys generated and used within our Novell 
> >International Cryptographic Infrastructure (NICI), even before S/MIME v3 
> >progresses to a full standard.  I'd be willing to assign an algorithm OID
> 
> >from the 
> >Novell tree, or we could probably get one from PKCS if there would be any
> 
> >problem getting one assigned by the IANA.
> >
> >Regards,
> >
> >Bob
> >
> >
> >> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
> >All:
> >
> >Right now, I am leaning toward the double encryption wrap algorithm.  I
> >think it will be easy to implement, and it yeilds a shorter result that
> the
> >OAEP method.  To convince myself that it was easy to implement, I did an
> >implementation.  It took me about two hours while watching an old Jimmy
> >Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
> >routines.  S/MIME v3 will require these algorithms for other capabilities
> >besides key wrapping.
> >
> >If someone else is willing to do an implementation, I would like to
> compare
> >results.  This will allow a test vector to be included with the algorithm
> >description.
> >
> >Does anyone have any strong objections to the double encryption wrap
> >algorithm being selected?
> >
> >Russ
> >
> >
> >>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
> >>
> >>Key Checksum
> >>
> >>The CMS Checksum Algorithm is used to provide an content-encryption key
> >>integrity check value.  The algorithm is:
> >>
> >>1.  Compute a 20 octet SHA-1 message digest on the 
> >>    content-encryption key.
> >>2.  Use the most significant (first) eight octets of the 
> >>    message digest value as the checksum value.
> >>
> >>Triple-DES Key Wrap
> >>
> >>1.  Set odd parity for each of the DES key octets comprising 
> >>    the content-encryption key, call the result CEK.
> >>2.  Compute a 8 octet key checksum value on CEK as described above,
> >>    call the result ICV.
> >>3.  Let CEKICV = CEK || ICV.
> >>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
> >>    an IV of 0xc302e3c1ad8bb738.
> >>5.  Reverse the order of the ciphertext octets.  That is, the most
> >>    significant (first) octet is swapped with the least significant
> >>    (last) octet, and so on.  Call the result TEMP.
> >>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use 
> >>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
> >
> >Robert R. Jueneman
> >Security Architect
> >Network Security Development
> >Novell, Inc.
> >122 East 1700 South
> >Provo, UT 84606
> >[email-masked] 
> >1-801-861-7387
> 

Date: Fri, 26 Feb 1999 11:38:19 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ:

You are correct, of course.  The question, then, is whether
we should just go to the OAEP-type wrapping and not have
to worry about changing IV's and how to convey them.
That would be my recommendation.

On a slightly different issue, several times I have strongly urged
that in order to avoid the problem of having N-squared algorithm
IDs for all of the various combinations of CEK and KEK algorithms,
key lengths, and other miscellaneous data, that we first wrap
the CEK in a descriptive ASN.1 structure that describes the 
the CEK algorithm/key, and then do the wrapping operation.

However, although I've raised this issue several times and indicated
our strong desire to solve the key wrapping issue once and for all,
you have neither incorporated the idea or argued against it,
so I don't know where you stand.

Obviously anyone who is processing certificates is going to have to 
have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures 
me that the performance implications would be negligible compared to
almost any encryption operation.

Assuming that is the case, the only reason I could see for not doing 
it would be concern about the increase in wrapped key size,
or some lingering not-invented-here bias against ISO/ITU/X.500
mechanisms.  I certainly hope it isn't the later.

Is there anything in the existing protocol that is rigidly sensitive to 
the size of the wrapped key?  If so, then that is a problem that 
probably ought to be addressed.

If not, then I believe the architectural benefits would far outweigh
any increase in the size of the wrapped key.

Bob

>>> Russ Housley <[email-masked]> 02/26/99 10:51AM >>>
Bob:

You raise an interesting point, but I think it can be easily solved by a
random IV for the first encryption. Of course, this makes the result one
block longer.  And, we would need a different IV for each wrapping.

Russ

At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
>Russ,
>
>There is a possible attack on the double encryption wrap algorithm 
>that is a result of the constant IV construction. For that reason, I would
>strongly prefer the OAEP construction. Although it may look complicated
>because there are more steps, the number of line of code is really of no 
>consequence at all, but the execution time is important for performance.
>
>Also, I continue to insist that we should not invent n-squared algorithm 
>IDs for every possible combination of CEK algorithm and key length
>plus KEK algorithm and key length. Instead, I would _greatly_ prefer to 
>first wrap the CEK in a ASN.1 structure that defines the CEK algorithm 
>and key length, then whiten that structure with OAEP, encrypt the resulting
>string with the KEK algorithm, and then provide generic instructions as
>to how to decode the result, either by wrapping the entire wrapped key 
>blob in ASN.1 (preferably) or some other way.
>
>Here's the attack on the double-encryption wrapping:
>
>Although most exhaustive search engines divide up the search process
>across multiple machines in order to find a single key as quickly as possible
>(e.g., the series of RSA challenge ciphers), there is another approach
>based on the use of an associative memory that I wrote up back
>in the '70's but never published.  I call it my "vacuum-cleaner" attack.
>
>Assume for the sake or argument that there are lots and lots of keys
>that have been or will be used to encrypt a known plaintext or 
>stereotyped message.  (This is a standard assumption in cryptanalysis.) 
>Actually, the attack will succeed with a somewhat weaker condition --
>it isn't necessary to actually know the plaintext -- it is sufficient that
>the plaintext be unvarying.
>
>Let's also assume that each key is used for some interesting purpose --
>sufficiently interesting that it may not be necessary to crack each and every
>key -- just a few would be useful.  For example, if I were trying to carry on 
>a credit card attack, I don't have to find the key for Bill Gates' or 
>Donald Trump's credit card -- just about anyone's will do, and the more 
>the merrier.
>
>So for every new key that I have the engine try, I contrive to compare 
>the result of encrypting the known plaintext against millions of valid 
>ciphertexts that have been intercepted, looking for a match.  Assuming 
>an effectively inexhaustible supply of ciphertexts is available, this attack 
>multiplies the effectiveness of the key search engine by an order of a million
>or more, depending on the size of the associative memory that is available.
>
>(The use of an associative memory isn't essential -- it was just a gedanken
>experiment to speed up the comparison process without requiring sorting.)
>
>Two things should be noted.  First, this attack is independent of the KEK 
>encryption algorithm used, assuming a fixed block size.  In other words, 
>this would apply to single-DES, triple-DES, umpty-DES, 2048-bit RSA,
>or whatever, assuming a constant session key and constant padding.
>
>Second, the attack is also independent of the length or type of session 
>key that is used, except that the yield is a Birthday Problem function of the
>length of the key.  But given a fixed input, i.e., no random whitening or 
>changing IV, then two or more matching outputs must imply a matching
>session key.  
>
>This leads to a rather surprising result -- even if the KEK performs double 
>encryption using triple-DES (or any other algorithm without whitening)
>to wrap a 40 bit key, two matching session keys can be found with 
>approximately 50% probability after only 2^20 or a million or so session 
>keys have been generated.
>
>Perhaps more surprisingly, at least to people who haven't been down this path,
>changing session keys more rapidly may hurt more than it helps -- it just 
>exposes that many more keys to attack. Changing the session key often 
>in the middle of a session may help limit the ability of the attacker to 
>access the entire message, and hence limits the attacker's "take," but it 
>increases the chances that a potentially interesting fragment of text 
>may be exposed.
>
>I'm sure that someone would observe that sending even a million content 
>encryption key encrypted in a constant KEK would be extremely unlikely
>in an S/MIME context, but whether that would really be true would require
>a more subtle, protocol-dependent analysis than I would care to make,
>and in addition I very much want to standardize on one key wrapping 
>algorithm that is protocol independent, and not just for S/MIME.
>
>Obviously the above attack can be defeated by prepending some 
>additional randomness or by changing the IV. But is also what the OAEP
>approach does, and rather more elegantly.  By the time we have to add
>either a changing IV or some additional randomness (how much would be
>required would have to be decided) the length would probably be close
>to that required for OAEP, which is a much more general solution.
>
>In my mind, at least, some extra bytes in the wrapped key is no big deal,
>but I would like the efficiency to be a good as possible. Triple-DES is 
>expensive enough in terms of computational efficiency in software, 
>especially in terms of the initial key expansion, and doing it twice 
>would be worse yet.
>
>Because the new export regulations permit the use of double the key length 
>used for data encryption to be used for key encryption, we are going to be
>using triple-DES in encrypt-decrypt-encrypt mode with only two keys
(A-B-A) for
>key wrapping of all export-grade CEK keys.
>
>This can be optimized by saving the key expansion of the first encryption,
and 
>then reusing it for the final encryption.  This technique could
potentially be 
>extended to the double encryption wrapping algorithm, by saving the key  
>expansion used for all three steps, but in order to do that the 
>"double-triple-DES"
>algorithm would probably have to be a single algorithm that is invoked --
>it would be quite difficult to securely save state across two separate 
>encryption
>operations.
>
>So my preference, as I said earlier, would be to wrap the CEK in ASN.1, 
>whiten with OAEP, and then encrypt using whatever KEK algorithm and 
>key length is required, so we don't have to keep re-analyzing this problem 
>for every new CEK or KEK algorithm or key length.
>
>If we can define appropriate algorithm IDs, I'm willing and eager to adopt
such
>a standard for  _all_ wrapped keys generated and used within our Novell 
>International Cryptographic Infrastructure (NICI), even before S/MIME v3 
>progresses to a full standard.  I'd be willing to assign an algorithm OID 
>from the 
>Novell tree, or we could probably get one from PKCS if there would be any 
>problem getting one assigned by the IANA.
>
>Regards,
>
>Bob
>
>
>> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
>All:
>
>Right now, I am leaning toward the double encryption wrap algorithm.  I
>think it will be easy to implement, and it yeilds a shorter result that the
>OAEP method.  To convince myself that it was easy to implement, I did an
>implementation.  It took me about two hours while watching an old Jimmy
>Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
>routines.  S/MIME v3 will require these algorithms for other capabilities
>besides key wrapping.
>
>If someone else is willing to do an implementation, I would like to compare
>results.  This will allow a test vector to be included with the algorithm
>description.
>
>Does anyone have any strong objections to the double encryption wrap
>algorithm being selected?
>
>Russ
>
>
>>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>>
>>Key Checksum
>>
>>The CMS Checksum Algorithm is used to provide an content-encryption key
>>integrity check value.  The algorithm is:
>>
>>1.  Compute a 20 octet SHA-1 message digest on the 
>>    content-encryption key.
>>2.  Use the most significant (first) eight octets of the 
>>    message digest value as the checksum value.
>>
>>Triple-DES Key Wrap
>>
>>1.  Set odd parity for each of the DES key octets comprising 
>>    the content-encryption key, call the result CEK.
>>2.  Compute a 8 octet key checksum value on CEK as described above,
>>    call the result ICV.
>>3.  Let CEKICV = CEK || ICV.
>>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>>    an IV of 0xc302e3c1ad8bb738.
>>5.  Reverse the order of the ciphertext octets.  That is, the most
>>    significant (first) octet is swapped with the least significant
>>    (last) octet, and so on.  Call the result TEMP.
>>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use 
>>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
>
>Robert R. Jueneman
>Security Architect
>Network Security Development
>Novell, Inc.
>122 East 1700 South
>Provo, UT 84606
>[email-masked] 
>1-801-861-7387

Date: Fri, 26 Feb 1999 13:07:02 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked]
Sender: [email-masked]

Peter:

I have a pseudo-random number generator that I am working on for a
different project.  I put a 0x484848...484848 seed into it and generated
the IVs.  Since no one has ever looked at that design I will get some new
ones from a better source.

We have hardware device that includes a random number generator.  I will
ask that device for some random numbers.

Russ

At 04:44 PM 2/20/99 +0000, Peter Gutmann wrote:
>Russ Housley <[email-masked]> wrote:
> 
>>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>>    an IV of 0xc302e3c1ad8bb738.
> 
>>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use
>>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
> 
>Could you provide a source for the values used for the IV's in the text?  
>Cryptographers get somewhat nervous about seeing magic numbers by themselves
>in specs.
> 
>Peter.
>

Date: Fri, 26 Feb 1999 13:01:28 -0500
To: "Don Johnson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Don:

In regard to number 3, it seems like using a random IV for the first
encryption is a very good idea.

Russ

At 11:07 AM 2/22/99 -0500, Don Johnson wrote:
>Russ,
>
>Here are some thoughts.
>
>1. Use of HMAC (using SHA-1) versus simple SHA-1 of the key may give
>security properties that are easier to show and be more conforming to
>existing stds. It can also grow easier, one never knows how these things
>might grow.
>2. You need to indicate if the parity bits are checked or not on recovery.
>I suggest that they should be checked, since they are set.  This provides
>some more integrity.
>3. The use of fixed IV's means that the first block of each encryption is
>less protected than the subsequent blocks.  This makes analysis more
>difficult.  If I were going to attack this method, I would concentrate on
>the less protected blocks, trying to find a match after less than 2**32
>encryptions.  This is not a complete idea but may be a start.  That is, the
>middle 2 blocks seem to collide in 2**32 encryptions, but the end blocks
>might collide sooner.
>4. I still think you should try to list some goals for this method.  For
>example, 64 bits of integrity, every bit depends on every other bit,
>confidentiality for key, etc.
>
>Don Johnson
>
>
>
>
>Russ Housley <[email-masked]> on 02/20/99 04:17:39 PM
>
>To:   [email-masked]
>cc:   [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked],
>      [email-masked] (bcc: Don Johnson/Certicom)
>Subject:  Re: A New Triple-DES Key Wrap Algorithm
>
>
>
>
>All:
>
>Right now, I am leaning toward the double encryption wrap algorithm.  I
>think it will be easy to implement, and it yeilds a shorter result that the
>OAEP method.  To convince myself that it was easy to implement, I did an
>implementation.  It took me about two hours while watching an old Jimmy
>Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
>routines.  S/MIME v3 will require these algorithms for other capabilities
>besides key wrapping.
>
>If someone else is willing to do an implementation, I would like to compare
>results.  This will allow a test vector to be included with the algorithm
>description.
>
>Does anyone have any strong objections to the double encryption wrap
>algorithm being selected?
>
>Russ
>
>
>>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>>
>>Key Checksum
>>
>>The CMS Checksum Algorithm is used to provide an content-encryption key
>>integrity check value.  The algorithm is:
>>
>>1.  Compute a 20 octet SHA-1 message digest on the
>>    content-encryption key.
>>2.  Use the most significant (first) eight octets of the
>>    message digest value as the checksum value.
>>
>>Triple-DES Key Wrap
>>
>>1.  Set odd parity for each of the DES key octets comprising
>>    the content-encryption key, call the result CEK.
>>2.  Compute a 8 octet key checksum value on CEK as described above,
>>    call the result ICV.
>>3.  Let CEKICV = CEK || ICV.
>>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>>    an IV of 0xc302e3c1ad8bb738.
>>5.  Reverse the order of the ciphertext octets.  That is, the most
>>    significant (first) octet is swapped with the least significant
>>    (last) octet, and so on.  Call the result TEMP.
>>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use
>>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
>
>
>
>

Date: Fri, 26 Feb 1999 12:51:44 -0500
To: "Bob Jueneman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Bob:

You raise an interesting point, but I think it can be easily solved by a
random IV for the first encryption. Of course, this makes the result one
block longer.  And, we would need a different IV for each wrapping.

Russ

At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
>Russ,
>
>There is a possible attack on the double encryption wrap algorithm 
>that is a result of the constant IV construction. For that reason, I would
>strongly prefer the OAEP construction. Although it may look complicated
>because there are more steps, the number of line of code is really of no 
>consequence at all, but the execution time is important for performance.
>
>Also, I continue to insist that we should not invent n-squared algorithm 
>IDs for every possible combination of CEK algorithm and key length
>plus KEK algorithm and key length. Instead, I would _greatly_ prefer to 
>first wrap the CEK in a ASN.1 structure that defines the CEK algorithm 
>and key length, then whiten that structure with OAEP, encrypt the resulting
>string with the KEK algorithm, and then provide generic instructions as
>to how to decode the result, either by wrapping the entire wrapped key 
>blob in ASN.1 (preferably) or some other way.
>
>Here's the attack on the double-encryption wrapping:
>
>Although most exhaustive search engines divide up the search process
>across multiple machines in order to find a single key as quickly as possible
>(e.g., the series of RSA challenge ciphers), there is another approach
>based on the use of an associative memory that I wrote up back
>in the '70's but never published.  I call it my "vacuum-cleaner" attack.
>
>Assume for the sake or argument that there are lots and lots of keys
>that have been or will be used to encrypt a known plaintext or 
>stereotyped message.  (This is a standard assumption in cryptanalysis.) 
>Actually, the attack will succeed with a somewhat weaker condition --
>it isn't necessary to actually know the plaintext -- it is sufficient that
>the plaintext be unvarying.
>
>Let's also assume that each key is used for some interesting purpose --
>sufficiently interesting that it may not be necessary to crack each and every
>key -- just a few would be useful.  For example, if I were trying to carry on 
>a credit card attack, I don't have to find the key for Bill Gates' or 
>Donald Trump's credit card -- just about anyone's will do, and the more 
>the merrier.
>
>So for every new key that I have the engine try, I contrive to compare 
>the result of encrypting the known plaintext against millions of valid 
>ciphertexts that have been intercepted, looking for a match.  Assuming 
>an effectively inexhaustible supply of ciphertexts is available, this attack 
>multiplies the effectiveness of the key search engine by an order of a million
>or more, depending on the size of the associative memory that is available.
>
>(The use of an associative memory isn't essential -- it was just a gedanken
>experiment to speed up the comparison process without requiring sorting.)
>
>Two things should be noted.  First, this attack is independent of the KEK 
>encryption algorithm used, assuming a fixed block size.  In other words, 
>this would apply to single-DES, triple-DES, umpty-DES, 2048-bit RSA,
>or whatever, assuming a constant session key and constant padding.
>
>Second, the attack is also independent of the length or type of session 
>key that is used, except that the yield is a Birthday Problem function of the
>length of the key.  But given a fixed input, i.e., no random whitening or 
>changing IV, then two or more matching outputs must imply a matching
>session key.  
>
>This leads to a rather surprising result -- even if the KEK performs double 
>encryption using triple-DES (or any other algorithm without whitening)
>to wrap a 40 bit key, two matching session keys can be found with 
>approximately 50% probability after only 2^20 or a million or so session 
>keys have been generated.
>
>Perhaps more surprisingly, at least to people who haven't been down this path,
>changing session keys more rapidly may hurt more than it helps -- it just 
>exposes that many more keys to attack. Changing the session key often 
>in the middle of a session may help limit the ability of the attacker to 
>access the entire message, and hence limits the attacker's "take," but it 
>increases the chances that a potentially interesting fragment of text 
>may be exposed.
>
>I'm sure that someone would observe that sending even a million content 
>encryption key encrypted in a constant KEK would be extremely unlikely
>in an S/MIME context, but whether that would really be true would require
>a more subtle, protocol-dependent analysis than I would care to make,
>and in addition I very much want to standardize on one key wrapping 
>algorithm that is protocol independent, and not just for S/MIME.
>
>Obviously the above attack can be defeated by prepending some 
>additional randomness or by changing the IV. But is also what the OAEP
>approach does, and rather more elegantly.  By the time we have to add
>either a changing IV or some additional randomness (how much would be
>required would have to be decided) the length would probably be close
>to that required for OAEP, which is a much more general solution.
>
>In my mind, at least, some extra bytes in the wrapped key is no big deal,
>but I would like the efficiency to be a good as possible. Triple-DES is 
>expensive enough in terms of computational efficiency in software, 
>especially in terms of the initial key expansion, and doing it twice 
>would be worse yet.
>
>Because the new export regulations permit the use of double the key length 
>used for data encryption to be used for key encryption, we are going to be
>using triple-DES in encrypt-decrypt-encrypt mode with only two keys
(A-B-A) for
>key wrapping of all export-grade CEK keys.
>
>This can be optimized by saving the key expansion of the first encryption,
and 
>then reusing it for the final encryption.  This technique could
potentially be 
>extended to the double encryption wrapping algorithm, by saving the key  
>expansion used for all three steps, but in order to do that the 
>"double-triple-DES"
>algorithm would probably have to be a single algorithm that is invoked --
>it would be quite difficult to securely save state across two separate 
>encryption
>operations.
>
>So my preference, as I said earlier, would be to wrap the CEK in ASN.1, 
>whiten with OAEP, and then encrypt using whatever KEK algorithm and 
>key length is required, so we don't have to keep re-analyzing this problem 
>for every new CEK or KEK algorithm or key length.
>
>If we can define appropriate algorithm IDs, I'm willing and eager to adopt
such
>a standard for  _all_ wrapped keys generated and used within our Novell 
>International Cryptographic Infrastructure (NICI), even before S/MIME v3 
>progresses to a full standard.  I'd be willing to assign an algorithm OID 
>from the 
>Novell tree, or we could probably get one from PKCS if there would be any 
>problem getting one assigned by the IANA.
>
>Regards,
>
>Bob
>
>
>> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
>All:
>
>Right now, I am leaning toward the double encryption wrap algorithm.  I
>think it will be easy to implement, and it yeilds a shorter result that the
>OAEP method.  To convince myself that it was easy to implement, I did an
>implementation.  It took me about two hours while watching an old Jimmy
>Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
>routines.  S/MIME v3 will require these algorithms for other capabilities
>besides key wrapping.
>
>If someone else is willing to do an implementation, I would like to compare
>results.  This will allow a test vector to be included with the algorithm
>description.
>
>Does anyone have any strong objections to the double encryption wrap
>algorithm being selected?
>
>Russ
>
>
>>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>>
>>Key Checksum
>>
>>The CMS Checksum Algorithm is used to provide an content-encryption key
>>integrity check value.  The algorithm is:
>>
>>1.  Compute a 20 octet SHA-1 message digest on the 
>>    content-encryption key.
>>2.  Use the most significant (first) eight octets of the 
>>    message digest value as the checksum value.
>>
>>Triple-DES Key Wrap
>>
>>1.  Set odd parity for each of the DES key octets comprising 
>>    the content-encryption key, call the result CEK.
>>2.  Compute a 8 octet key checksum value on CEK as described above,
>>    call the result ICV.
>>3.  Let CEKICV = CEK || ICV.
>>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>>    an IV of 0xc302e3c1ad8bb738.
>>5.  Reverse the order of the ciphertext octets.  That is, the most
>>    significant (first) octet is swapped with the least significant
>>    (last) octet, and so on.  Call the result TEMP.
>>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use 
>>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
>
>Robert R. Jueneman
>Security Architect
>Network Security Development
>Novell, Inc.
>122 East 1700 South
>Provo, UT 84606
>[email-masked]
>1-801-861-7387

Date: Fri, 26 Feb 1999 17:58:08 +0700 (GMT+0700)
From: Taweesak Chairatanayut <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: [email-masked]
Subject: RE: Question about security of header.
Sender: [email-masked]

On Fri, 26 Feb 1999, Blake Ramsdell wrote:
> 
> The outer RFC822 headers (Received, To, From, Subject, etc.) are not
> protected by the S/MIME v2 or v3 profile.
> 
> A way to do header authentication is to wrap an entire message/rfc822 in
> SignedData.

	As i know rfc822 header don't be signed in S/MIME, so how to wrap
an entire rfc822 header in SignedData ? 

Thank a lot for your help,
Pok.

		Mr. Taweesak Chairatanayut     < E-mail:[email-masked] >
				      System Engineer             
		--------------------------------------------------------
		            Network Technology Laboratory, 
		National  Electronics  and  Computer  Technology  Center
		  Tel: (662) 642-7077 Ext. 5010,   Fax: (662) 642-7064
		--------------------------------------------------------
				    ____   ____   _  _
				   (  _ \ (    ) ( \( )
				   |  __/ | ++ | | + (
				   (__)   (____) (_)\_)                      

From: "Blake Ramsdell" <[email-masked]>
To: "'Taweesak Chairatanayut'" <[email-masked]>, <[email-masked]>
Subject: RE: Question about security of header.
Date: Fri, 26 Feb 1999 02:34:23 -0800
Sender: [email-masked]

> -----Original Message-----
> From: Taweesak Chairatanayut [mailto:[email-masked]]
> Sent: Friday, February 26, 1999 1:41 AM
> To: [email-masked]
> Subject: Question about security of header.
> 
> 	According to rfc of S/MIME V.2.0, i have a question 
> about header.
> How can i be so sure that the header of e-mail didn't be 
> changed because
> from S/MIME V.2.0 i couldn't find that header can be 
> authenticated or not
> ( i think no, right ?). Do you have any idea of header 
> authentication ?
> Please advise.

The outer RFC822 headers (Received, To, From, Subject, etc.) are not
protected by the S/MIME v2 or v3 profile.

A way to do header authentication is to wrap an entire message/rfc822 in
SignedData.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 26 Feb 1999 16:41:12 +0700 (GMT+0700)
From: Taweesak Chairatanayut <[email-masked]>
To: [email-masked]
Subject: Question about security of header.
Sender: [email-masked]

Dear all,
	According to rfc of S/MIME V.2.0, i have a question about header.
How can i be so sure that the header of e-mail didn't be changed because
from S/MIME V.2.0 i couldn't find that header can be authenticated or not
( i think no, right ?). Do you have any idea of header authentication ?
Please advise.

Regards,
Pok.

		Mr. Taweesak Chairatanayut     < E-mail:[email-masked] >
				      System Engineer             
		--------------------------------------------------------
		            Network Technology Laboratory, 
		National  Electronics  and  Computer  Technology  Center
		  Tel: (662) 642-7077 Ext. 5010,   Fax: (662) 642-7064
		--------------------------------------------------------
				    ____   ____   _  _
				   (  _ \ (    ) ( \( )
				   |  __/ | ++ | | + (
				   (__)   (____) (_)\_)                      

From: William Ottaway <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Correct definition of ContentInfo in CMS-10
Date: Wed, 24 Feb 1999 14:08:36 -0000
Sender: [email-masked]

Russ:

To draw this thread to a close, the content within ContentInfo is not 
optional. Therefore, the ASN.1 in the appendix to CMS defining ContentInfo 
needs to have optional removed..

Bill.

-----Original Message-----
From:	Russ Housley [SMTP:[email-masked]]
Sent:	Wednesday, February 24, 1999 12:08 PM
To:	Bonatti, Chris
Cc:	SMIME
Subject:	RE: Correct definition of ContentInfo in CMS-10

Chris:

In PKCS#7 v1.5, ContentInfo was used as the outer wrapper (around
SignedData, EnvelopedData, etc) as well as the wrapper around the content
being protected.  In CMS, two different ASN.1 types are used for the two
different wrappers.  ContentInfo remains the outer wrapper.  There is no
need for such a wrapper without a protecting content such as SignedData,
EnvelopedData, etc., therefore the ContentInfo content should not be
optional.  The EncapsulatedContentInfo is the wrapper for the content being
protected.  To support a SignedData for distribution of certificates and
CRLs without any content (this approach is used in many products for
certificate user enrollment), EncapsulatedContentInfo has an OPTIONAL
content.

Russ

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]] On Behalf
Of Bonatti, Chris
Sent:	Monday, February 22, 1999 9:42 AM
To:	William Ottaway; [email-masked]'; Russ Housley
Subject:	Re: Correct definition of ContentInfo in CMS-10

    I would submit that the 'content' field in the General Syntax section 
is
correct.  The instance of OPTIONAL in the appendix must be a copy artifact
from the 'EncapsulatedContentInfo', in which the 'content' field is
correctly optional.  I can see no legitimate use of CMS in which you would
send only a 'contentType' OID.  Even if someone were sending a "detached
content" in a separate body part, either MIME or X.400 mail systems are
perfectly capable of attaching a content types for that information without
utilizing this structure.

Russ,

    Browsing through my historical archive of now "non-existent" I-Ds, I 
see
that the OPTIONAL tag seems to have fallen out of the General Syntax
starting in version 3 of CMS.  Do you remember the reasoning behind the
change?

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti             15309 Turkey Foot Road  |
 |  Principal Engineer              Darnestown, Md 20878-3640  |
 |  [email-masked]   Tel: 301-208-2349   Fax: 301-208-2379  |
 ---------------------------------------------------------------

____________________

William Ottaway wrote:

> Within the body of CMS 10 ContentInfo is defined as : -
>
> ContentInfo ::= SEQUENCE {
>         contentType ContentType,
>         content [0] EXPLICIT ANY DEFINED BY contentType }
>
> However, in the appendix ContentInfo is defined as : -
>
> ContentInfo ::= SEQUENCE {
>      contentType ContentType,
>      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>
> I assume the one within the body (i.e. content not optional) is correct.
>
> Bill.
>
> "The Information contained in this E-Mail and any subsequent
> correspondence is private and is intended solely for the intended
> recipient(s).  For those other than the intended recipient any
> disclosure, copying, distribution, or any action taken or omitted to
> be taken in reliance on such information is prohibited and may be
> unlawful."
> ____________________________________________________
> William Ottaway BSc Hons CEng MBCS,
> L323,                        Tel: +44 (0) 1684 894079
> DERA Malvern,                Fax: +44 (0) 1684 896113
> St. Andrews Road,            email: [email-masked]
> Malvern,
> Worcs,
> WR14 3PS
>
> All opinions are my own.

From: "Russ Housley" <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>
Cc: "SMIME" <[email-masked]>
Subject: RE: Correct definition of ContentInfo in CMS-10
Date: Wed, 24 Feb 1999 07:07:45 -0500
Importance: Normal
Sender: [email-masked]

Chris:

In PKCS#7 v1.5, ContentInfo was used as the outer wrapper (around
SignedData, EnvelopedData, etc) as well as the wrapper around the content
being protected.  In CMS, two different ASN.1 types are used for the two
different wrappers.  ContentInfo remains the outer wrapper.  There is no
need for such a wrapper without a protecting content such as SignedData,
EnvelopedData, etc., therefore the ContentInfo content should not be
optional.  The EncapsulatedContentInfo is the wrapper for the content being
protected.  To support a SignedData for distribution of certificates and
CRLs without any content (this approach is used in many products for
certificate user enrollment), EncapsulatedContentInfo has an OPTIONAL
content.

Russ

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]] On Behalf
Of Bonatti, Chris
Sent:	Monday, February 22, 1999 9:42 AM
To:	William Ottaway; [email-masked]'; Russ Housley
Subject:	Re: Correct definition of ContentInfo in CMS-10

    I would submit that the 'content' field in the General Syntax section is
correct.  The instance of OPTIONAL in the appendix must be a copy artifact
from the 'EncapsulatedContentInfo', in which the 'content' field is
correctly optional.  I can see no legitimate use of CMS in which you would
send only a 'contentType' OID.  Even if someone were sending a "detached
content" in a separate body part, either MIME or X.400 mail systems are
perfectly capable of attaching a content types for that information without
utilizing this structure.

Russ,

    Browsing through my historical archive of now "non-existent" I-Ds, I see
that the OPTIONAL tag seems to have fallen out of the General Syntax
starting in version 3 of CMS.  Do you remember the reasoning behind the
change?

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti             15309 Turkey Foot Road  |
 |  Principal Engineer              Darnestown, Md 20878-3640  |
 |  [email-masked]   Tel: 301-208-2349   Fax: 301-208-2379  |
 ---------------------------------------------------------------

____________________

William Ottaway wrote:

> Within the body of CMS 10 ContentInfo is defined as : -
>
> ContentInfo ::= SEQUENCE {
>         contentType ContentType,
>         content [0] EXPLICIT ANY DEFINED BY contentType }
>
> However, in the appendix ContentInfo is defined as : -
>
> ContentInfo ::= SEQUENCE {
>      contentType ContentType,
>      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>
> I assume the one within the body (i.e. content not optional) is correct.
>
> Bill.
>
> "The Information contained in this E-Mail and any subsequent
> correspondence is private and is intended solely for the intended
> recipient(s).  For those other than the intended recipient any
> disclosure, copying, distribution, or any action taken or omitted to
> be taken in reliance on such information is prohibited and may be
> unlawful."
> ____________________________________________________
> William Ottaway BSc Hons CEng MBCS,
> L323,                        Tel: +44 (0) 1684 894079
> DERA Malvern,                Fax: +44 (0) 1684 896113
> St. Andrews Road,            email: [email-masked]
> Malvern,
> Worcs,
> WR14 3PS
>
> All opinions are my own.

To: Dr Stephen Henson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
From: EKR <[email-masked]>
Date: 23 Feb 1999 08:04:22 -0800
Lines: 15
Sender: [email-masked]

Dr Stephen Henson <[email-masked]> writes:
> I originally put this forward as a throw away comment but since Burt
> Kaliski seemed to like the idea (it was me that made the initial
> suggestion: I think the quoting got messed up somewhere) I'll suggest it
> again a bit more formally as a possible alternative.
> 
> The idea is very simple. Treat the mailing list key (MLK) exactly as if
> it was a S-S DH shared secret ZZ. In particular a salt is mandatory and
> the KEK is derived using X9.42.
I think this is a good idea. I second it.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

Date: Tue, 23 Feb 1999 13:25:13 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

I originally put this forward as a throw away comment but since Burt
Kaliski seemed to like the idea (it was me that made the initial
suggestion: I think the quoting got messed up somewhere) I'll suggest it
again a bit more formally as a possible alternative.

The idea is very simple. Treat the mailing list key (MLK) exactly as if
it was a S-S DH shared secret ZZ. In particular a salt is mandatory and
the KEK is derived using X9.42.

IMHO this has several things in its favour.

1. Any conformant CMS implementation will already have implemented the
key derivation algorithm and test vectors already exist: which have been
independently checked.

2. The problem of using the same KEK a large number of times is avoided
because the mandatory use of a salt ensures the KEK is different each
time for a given MLK (assuming the salts are different of course).

3. The same MLK can be used with algortihms with different key sizes.

4. If there is a weakness with this algortithm then I would suggest
there must also be a weakness in S-S DH in which case we shouldn't be
using either.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
NOTE NEW (13/12/98) PGP key: via homepage.

From: Darren Harter <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Correct definition of ContentInfo in CMS-10
Date: Tue, 23 Feb 1999 08:41:07 -0000
Sender: [email-masked]

Peter,

You would be correct if we were talking about PKCS#7 where ContentInfo was used within SignedData to carry the content.  This would clearly have to be optional in the detached signature case.  But, in CMS we now only use ContentInfo for carrying SignedData, EnvelopedData etc., so even when detached signatures are being used the Content field of ContentInfo must be present to carry your SignedData.

I agree with John and other posters that the definition in the main body of the document is correct.  Content is not optional.

Regards,

Darren

--------------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions
E-Mail:	[email-masked]
Tel:	+44 (0) 1452 371 383, or +44 (0) 181 876 8666
Fax:	+44 (0) 1452 371 384, or +44 (0) 181 876 8660
Cell:	+44 (0) 7801 812 850

-----Original Message-----
From:	Peter Gutmann [SMTP:[email-masked]]
Sent:	Tuesday, February 23, 1999 3:46 AM
To:	[email-masked]; [email-masked]
Subject:	Re: Correct definition of ContentInfo in CMS-10
 
The content is optional.  Think about how detached sigs work.
 
Peter.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Josh Benaloh <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "Barb Fox (Exchange)" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: A New Triple-DES Key Wrap Algorithm
Date: Sat, 20 Feb 1999 18:26:11 -0800
Sender: [email-masked]

I agree with the amount of time that it takes to implement with a good
library.  It took me about 1.5 hours, but I was listing to A Prairie Home
Companion rather than watching a Jimmy Stewart movie.

The most difficult part of the process was convencing my decode routines
that PKCS#1 padding was not required to exist on the object.

Before you start producing test vectors, I want to see the expansion of the
algorithm to deal with the problems of encryption key material which does
not pad out to 8 byte boundries. What are you planning to do with lengths or
known padding for doing 40-bit RC2 keys.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Saturday, February 20, 1999 1:18 PM
To: [email-masked]

All:

Right now, I am leaning toward the double encryption wrap algorithm.  I
think it will be easy to implement, and it yeilds a shorter result that the
OAEP method.  To convince myself that it was easy to implement, I did an
implementation.  It took me about two hours while watching an old Jimmy
Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
routines.  S/MIME v3 will require these algorithms for other capabilities
besides key wrapping.

If someone else is willing to do an implementation, I would like to compare
results.  This will allow a test vector to be included with the algorithm
description.

Does anyone have any strong objections to the double encryption wrap
algorithm being selected?

Russ

>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>
>Key Checksum
>
>The CMS Checksum Algorithm is used to provide an content-encryption key
>integrity check value.  The algorithm is:
>
>1.  Compute a 20 octet SHA-1 message digest on the 
>    content-encryption key.
>2.  Use the most significant (first) eight octets of the 
>    message digest value as the checksum value.
>
>Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising 
>    the content-encryption key, call the result CEK.
>2.  Compute a 8 octet key checksum value on CEK as described above,
>    call the result ICV.
>3.  Let CEKICV = CEK || ICV.
>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>    an IV of 0xc302e3c1ad8bb738.
>5.  Reverse the order of the ciphertext octets.  That is, the most
>    significant (first) octet is swapped with the least significant
>    (last) octet, and so on.  Call the result TEMP.
>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use 
>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.

Date: Mon, 22 Feb 1999 10:50:12 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ,

There is a possible attack on the double encryption wrap algorithm 
that is a result of the constant IV construction. For that reason, I would
strongly prefer the OAEP construction. Although it may look complicated
because there are more steps, the number of line of code is really of no 
consequence at all, but the execution time is important for performance.

Also, I continue to insist that we should not invent n-squared algorithm 
IDs for every possible combination of CEK algorithm and key length
plus KEK algorithm and key length. Instead, I would _greatly_ prefer to 
first wrap the CEK in a ASN.1 structure that defines the CEK algorithm 
and key length, then whiten that structure with OAEP, encrypt the resulting
string with the KEK algorithm, and then provide generic instructions as
to how to decode the result, either by wrapping the entire wrapped key 
blob in ASN.1 (preferably) or some other way.

Here's the attack on the double-encryption wrapping:

Although most exhaustive search engines divide up the search process
across multiple machines in order to find a single key as quickly as possible
(e.g., the series of RSA challenge ciphers), there is another approach
based on the use of an associative memory that I wrote up back
in the '70's but never published.  I call it my "vacuum-cleaner" attack.

Assume for the sake or argument that there are lots and lots of keys
that have been or will be used to encrypt a known plaintext or 
stereotyped message.  (This is a standard assumption in cryptanalysis.) 
Actually, the attack will succeed with a somewhat weaker condition --
it isn't necessary to actually know the plaintext -- it is sufficient that
the plaintext be unvarying.

Let's also assume that each key is used for some interesting purpose --
sufficiently interesting that it may not be necessary to crack each and every
key -- just a few would be useful.  For example, if I were trying to carry on 
a credit card attack, I don't have to find the key for Bill Gates' or 
Donald Trump's credit card -- just about anyone's will do, and the more 
the merrier.

So for every new key that I have the engine try, I contrive to compare 
the result of encrypting the known plaintext against millions of valid 
ciphertexts that have been intercepted, looking for a match.  Assuming 
an effectively inexhaustible supply of ciphertexts is available, this attack 
multiplies the effectiveness of the key search engine by an order of a million
or more, depending on the size of the associative memory that is available.

(The use of an associative memory isn't essential -- it was just a gedanken
experiment to speed up the comparison process without requiring sorting.)

Two things should be noted.  First, this attack is independent of the KEK 
encryption algorithm used, assuming a fixed block size.  In other words, 
this would apply to single-DES, triple-DES, umpty-DES, 2048-bit RSA,
or whatever, assuming a constant session key and constant padding.

Second, the attack is also independent of the length or type of session 
key that is used, except that the yield is a Birthday Problem function of the
length of the key.  But given a fixed input, i.e., no random whitening or 
changing IV, then two or more matching outputs must imply a matching
session key.  

This leads to a rather surprising result -- even if the KEK performs double 
encryption using triple-DES (or any other algorithm without whitening)
to wrap a 40 bit key, two matching session keys can be found with 
approximately 50% probability after only 2^20 or a million or so session 
keys have been generated.

Perhaps more surprisingly, at least to people who haven't been down this path,
changing session keys more rapidly may hurt more than it helps -- it just 
exposes that many more keys to attack. Changing the session key often 
in the middle of a session may help limit the ability of the attacker to 
access the entire message, and hence limits the attacker's "take," but it 
increases the chances that a potentially interesting fragment of text 
may be exposed.

I'm sure that someone would observe that sending even a million content 
encryption key encrypted in a constant KEK would be extremely unlikely
in an S/MIME context, but whether that would really be true would require
a more subtle, protocol-dependent analysis than I would care to make,
and in addition I very much want to standardize on one key wrapping 
algorithm that is protocol independent, and not just for S/MIME.

Obviously the above attack can be defeated by prepending some 
additional randomness or by changing the IV. But is also what the OAEP
approach does, and rather more elegantly.  By the time we have to add
either a changing IV or some additional randomness (how much would be
required would have to be decided) the length would probably be close
to that required for OAEP, which is a much more general solution.

In my mind, at least, some extra bytes in the wrapped key is no big deal,
but I would like the efficiency to be a good as possible. Triple-DES is 
expensive enough in terms of computational efficiency in software, 
especially in terms of the initial key expansion, and doing it twice 
would be worse yet.

Because the new export regulations permit the use of double the key length 
used for data encryption to be used for key encryption, we are going to be
using triple-DES in encrypt-decrypt-encrypt mode with only two keys (A-B-A) for
key wrapping of all export-grade CEK keys.

This can be optimized by saving the key expansion of the first encryption, and 
then reusing it for the final encryption.  This technique could potentially be 
extended to the double encryption wrapping algorithm, by saving the key  
expansion used for all three steps, but in order to do that the "double-triple-DES"
algorithm would probably have to be a single algorithm that is invoked --
it would be quite difficult to securely save state across two separate encryption
operations.

So my preference, as I said earlier, would be to wrap the CEK in ASN.1, 
whiten with OAEP, and then encrypt using whatever KEK algorithm and 
key length is required, so we don't have to keep re-analyzing this problem 
for every new CEK or KEK algorithm or key length.

If we can define appropriate algorithm IDs, I'm willing and eager to adopt such
a standard for  _all_ wrapped keys generated and used within our Novell 
International Cryptographic Infrastructure (NICI), even before S/MIME v3 
progresses to a full standard.  I'd be willing to assign an algorithm OID from the 
Novell tree, or we could probably get one from PKCS if there would be any 
problem getting one assigned by the IANA.

Regards,

Bob

> Russ Housley <[email-masked]> 02/20/99 02:17PM >>>
All:

Right now, I am leaning toward the double encryption wrap algorithm.  I
think it will be easy to implement, and it yeilds a shorter result that the
OAEP method.  To convince myself that it was easy to implement, I did an
implementation.  It took me about two hours while watching an old Jimmy
Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
routines.  S/MIME v3 will require these algorithms for other capabilities
besides key wrapping.

If someone else is willing to do an implementation, I would like to compare
results.  This will allow a test vector to be included with the algorithm
description.

Does anyone have any strong objections to the double encryption wrap
algorithm being selected?

Russ

>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>
>Key Checksum
>
>The CMS Checksum Algorithm is used to provide an content-encryption key
>integrity check value.  The algorithm is:
>
>1.  Compute a 20 octet SHA-1 message digest on the 
>    content-encryption key.
>2.  Use the most significant (first) eight octets of the 
>    message digest value as the checksum value.
>
>Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising 
>    the content-encryption key, call the result CEK.
>2.  Compute a 8 octet key checksum value on CEK as described above,
>    call the result ICV.
>3.  Let CEKICV = CEK || ICV.
>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>    an IV of 0xc302e3c1ad8bb738.
>5.  Reverse the order of the ciphertext octets.  That is, the most
>    significant (first) octet is swapped with the least significant
>    (last) octet, and so on.  Call the result TEMP.
>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use 
>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

To: "Linn, John" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "Kaliski, Burt" <[email-masked]>
Subject: Re: Comments on x942-05 draft 
Date: Mon, 22 Feb 1999 09:14:20 -0800
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

> Here's some analysis on the RC2 effective key issue, thanks to Burt Kaliski.
[...]
Clearly we do have to defend against the partition attack on effective
key lengths. 

As John suggests, I propose that we place the RC2 effective key 
length into the the suppPubInfo. However, this leaves us with
an unfortunate inconsistency, in that for some algorithms it's
the length and some it's the effective length. One solution
to this would be to revert to what Stephen Henson has termed
the X/8 strategy. I.e. make the effective and real lengths
the same for RC2. This is slightly more tasteful than having
a bunch of special case language.

Comments? I'd like to get this settled quickly.

-Ekr
[Eric Rescorla                                   [email-masked]]

Date: Mon, 22 Feb 1999 08:24:50 -0800
From: Brian Korver <[email-masked]>
Reply-To: [email-masked]
To: William Ottaway <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Correct definition of ContentInfo in CMS-10
Sender: [email-masked]

William Ottaway wrote:
> 
> Within the body of CMS 10 ContentInfo is defined as : -
> 
> ContentInfo ::= SEQUENCE {
>         contentType ContentType,
>         content [0] EXPLICIT ANY DEFINED BY contentType }
> 
> However, in the appendix ContentInfo is defined as : -
> 
> ContentInfo ::= SEQUENCE {
>      contentType ContentType,
>      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
> 
> I assume the one within the body (i.e. content not optional) is correct.
> 
> Bill.

In PKCS#7, content is OPTIONAL.  But now with EncapsulatedContentInfo, CMS
doesn't use ContentInfo anyplace but the outer wrapper.

I'd be inclined to leave it OPTIONAL (I mean, what does it hurt?).  S/MIME
might not need it, but someone else might....

From: "Don Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 22 Feb 1999 11:07:32 -0500
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ,

Here are some thoughts.

1. Use of HMAC (using SHA-1) versus simple SHA-1 of the key may give
security properties that are easier to show and be more conforming to
existing stds. It can also grow easier, one never knows how these things
might grow.
2. You need to indicate if the parity bits are checked or not on recovery.
I suggest that they should be checked, since they are set.  This provides
some more integrity.
3. The use of fixed IV's means that the first block of each encryption is
less protected than the subsequent blocks.  This makes analysis more
difficult.  If I were going to attack this method, I would concentrate on
the less protected blocks, trying to find a match after less than 2**32
encryptions.  This is not a complete idea but may be a start.  That is, the
middle 2 blocks seem to collide in 2**32 encryptions, but the end blocks
might collide sooner.
4. I still think you should try to list some goals for this method.  For
example, 64 bits of integrity, every bit depends on every other bit,
confidentiality for key, etc.

Don Johnson

Russ Housley <[email-masked]> on 02/20/99 04:17:39 PM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked] (bcc: Don Johnson/Certicom)
Subject:  Re: A New Triple-DES Key Wrap Algorithm

All:

Right now, I am leaning toward the double encryption wrap algorithm.  I
think it will be easy to implement, and it yeilds a shorter result that the
OAEP method.  To convince myself that it was easy to implement, I did an
implementation.  It took me about two hours while watching an old Jimmy
Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
routines.  S/MIME v3 will require these algorithms for other capabilities
besides key wrapping.

If someone else is willing to do an implementation, I would like to compare
results.  This will allow a test vector to be included with the algorithm
description.

Does anyone have any strong objections to the double encryption wrap
algorithm being selected?

Russ

>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>
>Key Checksum
>
>The CMS Checksum Algorithm is used to provide an content-encryption key
>integrity check value.  The algorithm is:
>
>1.  Compute a 20 octet SHA-1 message digest on the
>    content-encryption key.
>2.  Use the most significant (first) eight octets of the
>    message digest value as the checksum value.
>
>Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising
>    the content-encryption key, call the result CEK.
>2.  Compute a 8 octet key checksum value on CEK as described above,
>    call the result ICV.
>3.  Let CEKICV = CEK || ICV.
>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>    an IV of 0xc302e3c1ad8bb738.
>5.  Reverse the order of the ciphertext octets.  That is, the most
>    significant (first) octet is swapped with the least significant
>    (last) octet, and so on.  Call the result TEMP.
>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use
>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.

From: "Ross demon" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Correct definition of ContentInfo in CMS-10
Date: Mon, 22 Feb 1999 15:37:26 -0000
Sender: [email-masked]

Peter,

When using detached signatures, I agree that the eContent is absent, but the
content is still required to convey the SignedData and hence the signature.
-----Original Message-----
From: Peter Gutmann <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Monday, February 22, 1999 3:04 PM
Subject: Re: Correct definition of ContentInfo in CMS-10

>>>Within the body of CMS 10 ContentInfo is defined as : -
>>>
>>>ContentInfo ::= SEQUENCE {
>>>        contentType ContentType,
>>>        content [0] EXPLICIT ANY DEFINED BY contentType }
>>>
>>>However, in the appendix ContentInfo is defined as : -
>>>
>>>ContentInfo ::= SEQUENCE {
>>>     contentType ContentType,
>>>     content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>>>
>>>I assume the one within the body (i.e. content not optional) is correct.
>
>>I assume that content is not optional
>
>The content is optional.  Think about how detached sigs work.
>
>Peter.
>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Correct definition of ContentInfo in CMS-10
Reply-To: [email-masked]
Date: Tue, 23 Feb 1999 03:46:28 (NZDT)
Sender: [email-masked]

>>Within the body of CMS 10 ContentInfo is defined as : -
>>
>>ContentInfo ::= SEQUENCE {
>>        contentType ContentType,
>>        content [0] EXPLICIT ANY DEFINED BY contentType }
>>
>>However, in the appendix ContentInfo is defined as : -
>>
>>ContentInfo ::= SEQUENCE {
>>     contentType ContentType,
>>     content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>>
>>I assume the one within the body (i.e. content not optional) is correct.
 
>I assume that content is not optional
 
The content is optional.  Think about how detached sigs work.
 
Peter.

Date: Mon, 22 Feb 1999 09:42:09 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: William Ottaway <[email-masked]>, "[email-masked]'" <[email-masked]>, Russ Housley <[email-masked]>
Subject: Re: Correct definition of ContentInfo in CMS-10
Sender: [email-masked]

    I would submit that the 'content' field in the General Syntax section is
correct.  The instance of OPTIONAL in the appendix must be a copy artifact
from the 'EncapsulatedContentInfo', in which the 'content' field is
correctly optional.  I can see no legitimate use of CMS in which you would
send only a 'contentType' OID.  Even if someone were sending a "detached
content" in a separate body part, either MIME or X.400 mail systems are
perfectly capable of attaching a content types for that information without
utilizing this structure.

Russ,

    Browsing through my historical archive of now "non-existent" I-Ds, I see
that the OPTIONAL tag seems to have fallen out of the General Syntax
starting in version 3 of CMS.  Do you remember the reasoning behind the
change?

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti             15309 Turkey Foot Road  |
 |  Principal Engineer              Darnestown, Md 20878-3640  |
 |  [email-masked]   Tel: 301-208-2349   Fax: 301-208-2379  |
 ---------------------------------------------------------------

____________________

William Ottaway wrote:

> Within the body of CMS 10 ContentInfo is defined as : -
>
> ContentInfo ::= SEQUENCE {
>         contentType ContentType,
>         content [0] EXPLICIT ANY DEFINED BY contentType }
>
> However, in the appendix ContentInfo is defined as : -
>
> ContentInfo ::= SEQUENCE {
>      contentType ContentType,
>      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>
> I assume the one within the body (i.e. content not optional) is correct.
>
> Bill.
>
> "The Information contained in this E-Mail and any subsequent
> correspondence is private and is intended solely for the intended
> recipient(s).  For those other than the intended recipient any
> disclosure, copying, distribution, or any action taken or omitted to
> be taken in reliance on such information is prohibited and may be
> unlawful."
> ____________________________________________________
> William Ottaway BSc Hons CEng MBCS,
> L323,                        Tel: +44 (0) 1684 894079
> DERA Malvern,                Fax: +44 (0) 1684 896113
> St. Andrews Road,            email: [email-masked]
> Malvern,
> Worcs,
> WR14 3PS
>
> All opinions are my own.

From: "John Ross" <[email-masked]>
To: "William Ottaway" <[email-masked]>, <[email-masked]>
Subject: Re: Correct definition of ContentInfo in CMS-10
Date: Mon, 22 Feb 1999 14:17:13 -0800
Sender: [email-masked]

I assume that content is not optional
-----Original Message-----
From: William Ottaway <[email-masked]>
To: [email-masked]' <[email-masked]>
Date: Monday, February 22, 1999 5:27 AM
Subject: Correct definition of ContentInfo in CMS-10

>Within the body of CMS 10 ContentInfo is defined as : -
>
>ContentInfo ::= SEQUENCE {
>        contentType ContentType,
>        content [0] EXPLICIT ANY DEFINED BY contentType }
>
>However, in the appendix ContentInfo is defined as : -
>
>ContentInfo ::= SEQUENCE {
>     contentType ContentType,
>     content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>
>I assume the one within the body (i.e. content not optional) is correct.
>
>Bill.
>
>
>"The Information contained in this E-Mail and any subsequent
>correspondence is private and is intended solely for the intended
>recipient(s).  For those other than the intended recipient any
>disclosure, copying, distribution, or any action taken or omitted to
>be taken in reliance on such information is prohibited and may be
>unlawful."
>____________________________________________________
>William Ottaway BSc Hons CEng MBCS,
>L323,                        Tel: +44 (0) 1684 894079
>DERA Malvern,                Fax: +44 (0) 1684 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs,
>WR14 3PS
>
>All opinions are my own.
>

From: "Ross demon" <[email-masked]>
To: "William Ottaway" <[email-masked]>, <[email-masked]>
Subject: Re: Correct definition of ContentInfo in CMS-10
Date: Mon, 22 Feb 1999 13:45:08 -0000
Sender: [email-masked]

I assume that content is not optional
-----Original Message-----
From: William Ottaway <[email-masked]>
To: [email-masked]' <[email-masked]>
Date: Monday, February 22, 1999 1:27 PM
Subject: Correct definition of ContentInfo in CMS-10

>Within the body of CMS 10 ContentInfo is defined as : -
>
>ContentInfo ::= SEQUENCE {
>        contentType ContentType,
>        content [0] EXPLICIT ANY DEFINED BY contentType }
>
>However, in the appendix ContentInfo is defined as : -
>
>ContentInfo ::= SEQUENCE {
>     contentType ContentType,
>     content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>
>I assume the one within the body (i.e. content not optional) is correct.
>
>Bill.
>
>
>"The Information contained in this E-Mail and any subsequent
>correspondence is private and is intended solely for the intended
>recipient(s).  For those other than the intended recipient any
>disclosure, copying, distribution, or any action taken or omitted to
>be taken in reliance on such information is prohibited and may be
>unlawful."
>____________________________________________________
>William Ottaway BSc Hons CEng MBCS,
>L323,                        Tel: +44 (0) 1684 894079
>DERA Malvern,                Fax: +44 (0) 1684 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs,
>WR14 3PS
>
>All opinions are my own.
>

From: William Ottaway <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Correct definition of ContentInfo in CMS-10
Date: Mon, 22 Feb 1999 13:00:21 -0000
Sender: [email-masked]

Within the body of CMS 10 ContentInfo is defined as : -

ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

However, in the appendix ContentInfo is defined as : -

ContentInfo ::= SEQUENCE {
     contentType ContentType,
     content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

I assume the one within the body (i.e. content not optional) is correct.

Bill.

"The Information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s).  For those other than the intended recipient any
disclosure, copying, distribution, or any action taken or omitted to
be taken in reliance on such information is prohibited and may be
unlawful."
____________________________________________________
William Ottaway BSc Hons CEng MBCS,
L323,                        Tel: +44 (0) 1684 894079
DERA Malvern,                Fax: +44 (0) 1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs,
WR14 3PS

All opinions are my own.

Date: Sat, 20 Feb 1999 16:17:39 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

All:

Right now, I am leaning toward the double encryption wrap algorithm.  I
think it will be easy to implement, and it yeilds a shorter result that the
OAEP method.  To convince myself that it was easy to implement, I did an
implementation.  It took me about two hours while watching an old Jimmy
Stewart movie.  Of course, I already have SHA-1 and Triple-DES CBC
routines.  S/MIME v3 will require these algorithms for other capabilities
besides key wrapping.

If someone else is willing to do an implementation, I would like to compare
results.  This will allow a test vector to be included with the algorithm
description.

Does anyone have any strong objections to the double encryption wrap
algorithm being selected?

Russ

>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>
>Key Checksum
>
>The CMS Checksum Algorithm is used to provide an content-encryption key
>integrity check value.  The algorithm is:
>
>1.  Compute a 20 octet SHA-1 message digest on the 
>    content-encryption key.
>2.  Use the most significant (first) eight octets of the 
>    message digest value as the checksum value.
>
>Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising 
>    the content-encryption key, call the result CEK.
>2.  Compute a 8 octet key checksum value on CEK as described above,
>    call the result ICV.
>3.  Let CEKICV = CEK || ICV.
>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>    an IV of 0xc302e3c1ad8bb738.
>5.  Reverse the order of the ciphertext octets.  That is, the most
>    significant (first) octet is swapped with the least significant
>    (last) octet, and so on.  Call the result TEMP.
>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use 
>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: More on KEKIdentifiers, and a suggested addition to CMS
Reply-To: [email-masked]
Date: Sun, 21 Feb 1999 04:19:18 (NZDT)
Sender: [email-masked]

I don't know what the final resolution on optional vs mandatory KEKIdentifiers 
was, but I note that PKCS #15, which AFAIK is the first non-S/MIME use of CMS 
KEK encryption, already has to explicitly state that KEKIdentifiers are null 
strings wherever they occur because they're not useful for anything (actually 
there's a "not recommended" special-case use for them, see below).  I think 
this proves my earlier point that there's going to be very little use for a 
KEKIdentifier outside S/MIME, so that making it optional would be a good idea.
 
Looking at the way KEKRecipientInfo is being used in PKCS #15, there's a 
rather obvious recipient type missing from CMS: Password-based encryption.  
PKCS #15 has a hack for this which puts the key derivation information into 
the KEKIdentifier (this being the special-case use mentioned above), but I'm 
sure this isn't what it was intended for because it isn't a key identifier at 
all but contains the AlgorithmIdentifier for the password processing.  What's 
really needed is a new recipient type, PasswordRecipientInfo.  Included below 
is a suggestion for this which could drop directly into the CMS draft.
 
Peter.
 
-- Snip --
 
6.2.4  PasswordRecipientInfo Type
 
   Recipient information using a user-supplied password is represented in the
   type PasswordRecipientInfo.  Each instance of PasswordRecipientInfo will
   transfer the content-encryption key to one or more recipients who have the
   previously agreed-upon password.
 
      PasswordRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 0
        keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
        keyEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }
 
   The fields of type PasswordRecipientInfo have the following meanings:
 
      version is the syntax version number.  It shall always be 0.
 
      keyDerivationAlgorithm identifies the key-derivation algorithm, and any
      associated parameters, used to derive the key-encryption key from the
      user-supplied password.
 
      keyEncryptionAlgorithm identifies the content-encryption algorithm, and
      any associated parameters, used to encrypt the content-encryption key
      with the password-derived key-encryption key.
 
      encryptedKey is the result of encrypting the content-encryption key with
      the password-derived key-encryption key.
 
   The key derivation algorithms are:
 
      KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
        { IDENTIFIED BY id-PBKDF2 },
        ...
        }
 
    For key derivation, CMS implementations must include PBKDF2 [PKCS5v2].
                        
    For content (= key) encryption, CMS implementations must include Triple-DES 
    in CBC mode, should include RC2 in CBC mode, and may include other 
    algorithms (CAST-128, RC5, IDEA, Skipjack) and modes as required.  CMS 
    implementations should not include any KSG ciphers such as RC4.
 
-- Snip --
 
Comments:
 
The ContentEncryptionAlgorithmIdentifier is something like:
 
      ContentEncryptionAlgorithmIdentifier ::= {
        { IDENTIFIED BY des-ede3-cbc },
        { IDENTIFIED BY rc2CBC },
        { IDENTIFIED BY cast5CBC },
        { IDENTIFIED BY rc5CBC },
        { IDENTIFIED BY ideaCBC },
        { IDENTIFIED BY desCBC },
        ... -- ... and anything else you can think of, eg Skipjack
        }
 
but enumerating every possible one is superfluous as they're specified 
elsewhere.
 
The content is encrypted is as per the KEK algorithm, but using the IV given 
in the ContentEncryptionAlgorithmIdentifier instead of a fixed IV - this is 
just standard CMS content encryption.  The advantage of using standard OIDs is 
that it doesn't require defining a completely new set of OIDs which parallel 
all of the existing ones just to show that you're encrypting a key.  Another 
way to handle this is as EncryptedContentInfo (which just adds an extra 
SEQUENCE around the existing ContentEncryptionAlgorithmIdentifier + 
EncryptedContent (=EncryptedKey)), but this is probably going overboard.
 
(I'm prepared to accept a 'kekid [0] KEKIdentifier OPTIONAL' after the version 
 number if that's what's required to get people's grunt of approval for the 
 thing).
 
(Before people complain that you can't change the key wrap algorithm, if it 
 ever does become necessary to change it (and I thought the point of the 
 current key wrap design process was to build a solution once and for all), 
 all you need to do is increment the RecipientInfo version number and add 
 whatever you feel like).
 
Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: A New Triple-DES Key Wrap Algorithm
Reply-To: [email-masked]
Date: Sat, 20 Feb 1999 16:44:49 (NZDT)
Sender: [email-masked]

Russ Housley <[email-masked]> wrote:
 
>4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>    an IV of 0xc302e3c1ad8bb738.
 
>6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use
>    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.
 
Could you provide a source for the values used for the IV's in the text?  
Cryptographers get somewhat nervous about seeing magic numbers by themselves
in specs.
 
Peter.

Date: Fri, 19 Feb 1999 15:46:15 -0500
To: "Linn, John" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Comments on x942-05 draft
Cc: "'EKR'" <[email-masked]>, [email-masked]
Sender: [email-masked]

John:

You are correct.  There seems to be a typo.  p needs to be bigger than q and x.

Russ

At 08:27 AM 2/19/99 -0500, Linn, John wrote:
>I'm trying to mind p's and q's here ;-).  I was questioning the last
>sentence in 2.2's 2nd paragraph, which states "p must be a minimum of 160
>bits long", recognizing X9.42's recommendation for a significantly larger p.
>Earlier in the same paragraph, there's a separate statement about q being at
>least 160 bits; I wasn't asking about that or private key sizes, just
>specifically about p. 
>
>--jl
>
>> ----------
>> From: 	EKR[SMTP:[email-masked]]
>> Sent: 	Wednesday, February 17, 1999 5:19 PM
>> To: 	Russ Housley
>> Cc: 	[email-masked]; [email-masked]
>> Subject: 	Re: Comments on x942-05 draft
>> 
>> Russ Housley <[email-masked]> writes:
>> 
>> > John said:
>> > >> In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m
>> MUST
>> > >> be >= 160 bits in length". Later in the paragraph, is 160 bits
>> intended as
>> > >> the appropriate minimum length for p?  (Note, by comparison, that
>> X9.42
>> > >> requires a multiple of 256 bits with a minimum of 512.)
>> > 
>> > Then Eric replied:
>> > >I'd prefer 160. 512 seems like overkill, and has unpleasant performance
>> > >tradeoffs.
>> > 
>> > I do not have a problem allowing people to have 512-bit private keys.
>> The
>> > performance impact is imposed on themselves.  I also think that we
>> should
>> > permit 160-bit private keys for those people that belive 80-bit security
>> is
>> > useful.
>> > 
>> > In summary, I think that we should allow private keys to be between 160
>> and
>> > 512 bits.
>> That's no problem, but John indicates that X9.42 has a MINIMUM of 512,
>> which I consider unacceptable.
>> 
>> As far as I'm concerned people should be allowed to go up to |p|
>> 
>> -Ekr
>> 
>> 
>> -- 
>> [Eric Rescorla                                   [email-masked]]
>> 

Date: Fri, 19 Feb 1999 14:32:21 -0500
To: Hilton Day <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Selecting key-management algorithm...
Cc: [email-masked]
Sender: [email-masked]

Ephemeral-Static Diffie-Hellman is the mandatory to implement algorithm to
ensure interoperability.  Since Ephemeral-Static Diffie-Hellman is a key
agreement algorithm, that is the mandatory to implement portion of the
protocol.

Russ

At 03:08 PM 2/18/99 +0000, Hilton Day wrote:
>Hi all,
>
>What (if anything) denotes whether a CMS message should use KA or KT as the
>key-management algorithm?
>
>I've looked through the spec, and can't see anything which mandates a method 
>for
>doing this, so I can only assume it is an implementation-specific choice (i.e.
>User-input, or the programmers decide when writing the mail client, based on
>security policy).
>
>This leaves me wondering why KA is a "must" for the CMS - it is conveivable 
>that
>KA would never be used within the context of S/MIME, as mail clients could 
>simply
>use KT to wrap their CEK's.
>
>Ok - I realise that in the interests of interoperability, KA should be 
>implemented
>in order that a recipient can read a mail sent with a shared-secret-based 
>key, but
>in the same way as Symmetric Key-Encryption Key algorithms are a "may", surely
>this is something for the implementor to decide?
>
>I realise that, as I've only been following the spec. since CMS-09, I've 
>probably
>already missed conversations along these lines, in which case, apologies
to all
>those who've hashed over this - but I'd appreciate an explanation.. :-)
>
>Thanks,
>
>Hilton.
>
>--
>JCP Computer Services           Tel:    +44 (0) 171 689 6890
>16 St Johns Lane,               Fax:    +44 (0) 171 689 0438
>London,                         E-Mail: [email-masked]
>EC1M 4BS                        WWW:    http://www.jcp.co.uk
>United Kingdom
>
>

From: "Linn, John" <[email-masked]>
To: "Linn, John" <[email-masked]>, "'EKR'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Kaliski, Burt" <[email-masked]>
Subject: RE: Comments on x942-05 draft
Date: Fri, 19 Feb 1999 08:50:30 -0500
Sender: [email-masked]

Here's some analysis on the RC2 effective key issue, thanks to Burt Kaliski.

> ----------
> From: 	EKR[SMTP:[email-masked]]
> Sent: 	Wednesday, February 17, 1999 2:09 PM
> To: 	Linn, John
> Cc: 	[email-masked]'
> Subject: 	Re: Comments on x942-05 draft
> 
> "Linn, John" <[email-masked]> writes:
> > In sec. 2.1.2, description of "algorithm": suggest adding the following
> > sentence at end: "As an implication, it may be appropriate for
> algorithms
> > employing variable parameters other than key size to be represented with
> > different OIDs corresponding to different parameter combinations, if
> > parameter values cannot be unambiguously determined from usage context".
> As
> > a related point, would it be acceptable to state that the structure of
> > suppPubInfo may be defined on a per-algorithm basis?   For the case of
> RC2
> > usage in S/MIME, where the key length is fixed to 128 bits, it seems to
> > offer more protective value to represent the variable effective key
> length
> > within suppPubInfo than to represent the fixed 128 bit length. 
> Is this necessary? The simple partition attack obviously doesn't work.
> Given knowledge about the 40-bit "effective key" generated by a given
> 128 bit key, do you get information about the 128-bit "effective key"
> that would be generated?
> 
An RC2 key has actual length t (fixed to 128 for S/MIME purposes) and
effective length k.  RC2 key setup has two phases: (1) map t-bit actual key
into t-bit state, then (2) map last k bits of state into 128-byte table.
Partitioning can therefore take place in the state space.  If an actual key
is used for both k=40 and k=128, an opponent can solve for the last 40 bits
of the state by a 2^40 exhaustive search against data encrypted with k=40.

--jl

From: "Linn, John" <[email-masked]>
To: Russ Housley <[email-masked]>, "'EKR'" <[email-masked]>
Cc: "Linn, John" <[email-masked]>, [email-masked]
Subject: RE: Comments on x942-05 draft
Date: Fri, 19 Feb 1999 08:27:32 -0500
Sender: [email-masked]

I'm trying to mind p's and q's here ;-).  I was questioning the last
sentence in 2.2's 2nd paragraph, which states "p must be a minimum of 160
bits long", recognizing X9.42's recommendation for a significantly larger p.
Earlier in the same paragraph, there's a separate statement about q being at
least 160 bits; I wasn't asking about that or private key sizes, just
specifically about p. 

--jl

> ----------
> From: 	EKR[SMTP:[email-masked]]
> Sent: 	Wednesday, February 17, 1999 5:19 PM
> To: 	Russ Housley
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: Comments on x942-05 draft
> 
> Russ Housley <[email-masked]> writes:
> 
> > John said:
> > >> In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m
> MUST
> > >> be >= 160 bits in length". Later in the paragraph, is 160 bits
> intended as
> > >> the appropriate minimum length for p?  (Note, by comparison, that
> X9.42
> > >> requires a multiple of 256 bits with a minimum of 512.)
> > 
> > Then Eric replied:
> > >I'd prefer 160. 512 seems like overkill, and has unpleasant performance
> > >tradeoffs.
> > 
> > I do not have a problem allowing people to have 512-bit private keys.
> The
> > performance impact is imposed on themselves.  I also think that we
> should
> > permit 160-bit private keys for those people that belive 80-bit security
> is
> > useful.
> > 
> > In summary, I think that we should allow private keys to be between 160
> and
> > 512 bits.
> That's no problem, but John indicates that X9.42 has a MINIMUM of 512,
> which I consider unacceptable.
> 
> As far as I'm concerned people should be allowed to go up to |p|
> 
> -Ekr
> 
> 
> -- 
> [Eric Rescorla                                   [email-masked]]
> 

Date: Thu, 18 Feb 1999 17:52:24 -0500
To: Hilton Day <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Selecting key-management algorithm...
Sender: [email-masked]

Hilton,

The KeyTransRecipientInfo syntax does not include a field to carry or
identify the originator's key management public key.  This is required for
key agreement algorithms such as D-H.

The recipient's cert indicates which flavor must be used.  If it is a key
transfer algorithm such as RSA, then the KeyTransRecipientInfo syntax is
used.  If it is a key agreement algorithm such as D-H, then the
KeyAgreeRecipientInfo syntax is used.  

=========================================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
[email-masked]
=========================================================

From: Burt Kaliski <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Ron Rivest <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: A New Triple-DES Key Wrap Algorithm
Date: Thu, 18 Feb 1999 07:34:00 -0800
Sender: [email-masked]

Regarding Russ's question:

> Has the double-encryption approach that we are considering been analyzed
> as
> an AONT?  If so, how does it stack up when compared to OAEP?
> 
I'm not aware of any similar analysis on double-encryption, though it would
be an interesting (and not necessarily easy) research exercise. I've asked
Victor Boyko if he's interested in taking a look.

Responding to Bob Jueneman's earlier suggestion:

	Is there some specific need to use the same KEK for mailing lists
	multiple times or could the same solution be used as in S-S DH? 

	In other words make the use of a "salt" in the message compulsory
and
	use the mailing list key in place of the DH shared secret (ZZ). This
	would then allow the same mailing list key to be used multiple times
	because the KEK would be different with each salt.

I think this is architecturally a nice approach, since with static-static
Diffie-Hellman, ZZ is a shared key between two users, and KEKs are derived
from it. The goal is to use a KEK only once in either setting.

-- Burt

From: Burt Kaliski <[email-masked]>
To: Bob Jueneman <[email-masked]>, "'Don Johnson'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Ron Rivest <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: A New Triple-DES Key Wrap Algorithm
Date: Thu, 18 Feb 1999 07:25:12 -0800
Sender: [email-masked]

Right, the 2^32 limitation for a 64-bit block cipher in CBC mode is not a
new result, though I'm not sure how far back it goes. I've merely made the
observation that due to those limitations, it may not be appropriate to
encrypt a message containing a key and fixed padding in CBC mode. Encrypting
an appropriate function of the message (e.g. OAEP) or encrypting twice is
better.

-- Burt

> ----------
> From: 	Don Johnson[SMTP:[email-masked]]
> Sent: 	Tuesday, February 16, 1999 9:37 PM
> To: 	Bob Jueneman
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Burt Kaliski; [email-masked];
> [email-masked]; [email-masked]; Ron Rivest; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: 	Re: A New Triple-DES Key Wrap Algorithm
> 
> Just for the record, text attacks such as Burt mentioned were discussed by
> Coppersmith, Johnson and Matyas in their paper on CBCM mode of Triple DES
> as a justification for considering it in ANSI X9.  They might have been
> known before that, but the ref in the HAC is to that paper, so I know of
> no
> earlier ref.
> 
> Don J.
> 
> 
> 
> 
> 
> "Bob Jueneman" <[email-masked]> on 02/16/99 08:53:37 PM
> 
> To:   [email-masked], [email-masked]
> cc:   [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked],
>       [email-masked], [email-masked],
>       [email-masked], [email-masked],
>       [email-masked], [email-masked],
>       [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked],
>       [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked], [email-masked],
>       [email-masked] (bcc: Don Johnson/Certicom)
> Subject:  Re: A New Triple-DES Key Wrap Algorithm
> 
> 
> 
> 
> David,
> 
> The reason why I got interested in this subject at all was that I realized
> that within
> Novell's cryptographic architecture we wrap all sorts of keys, and when a
> possible
> attack was pointed out I became concerned.
> 
> I understand Russ Housley's point about wanting to solve this problem for
> S/MIME --
> that is his charter, and he wants to deliver a product.  Admirable
> dedication.  And I
> certainly agree with you that there are other, probably more effective
> ways
> to
> compromise S/MIME. than by mailing a billion keys around!
> 
> But as a vendor, I don't want to have to solve the key wrapping problem
> one
> way
> for S/MIME, plus N other ways for the next N protocols to come along.
> 
> Believe me, it is very tough to get the attention of the real experts in
> this area,
> and so once the problem was raised, I think we should solve it as best we
> can,
> once and for all. The S/MIME spec will then make a convenient point of
> reference
> for something that was done right.
> 
> For that reason, then, I would tend to dismiss any and all arguments about
> whether
> some particular attack might or might not be feasible in an S/MIME context
> -- that type of
> subtlety is exceedingly hard to get right, and besides I want a more
> general purpose
> solution.
> 
> Although Steve Kent's argument about the cost of changing keys often is
> quite valid,
> your argument about wanting to refresh your KEKs more often is NOT
> necessarily
> the way to improve security. It depends upon the threat.
> 
> Most approaches to brute force attacks try to speed up the number of key
> search
> operations that can be done simultaneously or in parallel, e.g., the
> recent
> success
> at the RSA conference of the EFF's Deep Crack engine in combination with
> lots of
> distributed computers, all working on the same challenge cipher.
> 
> But there is another approach, which I call the vacuum cleaner technique,
> where you
> don't target any specific key, but rather you suck up million or billions
> of keys and
> process all of them simultaneously. With this approach, for every new key
> that is
> tried, either singly or in parallel, the attacker looks at billions of
> ciphertexts to see
> if the result of encrypting a chosen plaintext with a given key matches
> any
> one of the
> ciphertexts that have been collected. (This assumes a chosen plaintext
> attack is
> feasible, which is the usual conservative assumption.)  In other words,
> don't look for
> a needle in a haystack -- take the entire haystack.
> 
> After all, if I am trying to steal credit card numbers, I don't care much
> whose credit card it is --
> I'm not trying to target Bill Gates or Donald Trump specifically -- I'll
> settle for yours or
> almost anybody else's.
> 
> In this scenario, increasing the number of KEKs that are used actually
> _increases_
> my chances of success, for it gives me that many more ciphertext examples
> to look at,
> assuming that success is measured in terms of how many keys are cracked in
> a
> given amount of time, rather than how long it takes to crack a specific
> key.
> 
> Bob
> 
> 
> 
> >>> David Wagner <[email-masked]> 02/15/99 03:42PM >>>
> > David:
> >
> > I had the same reaction to the 4 billion wrapped keys; however, there
> are
> > two reasons why we should address this issue.  First, when mail list
> keys
> > are used, the same KEK is used to encrypt CEKs for every message sent to
> > the mail list.  Depending on the activity on the mail list ad the
> > cryptoperiod of the KEK, the 4 billion wrapped keys might actually
> happen,
> > especially if severs ever communicated with each other using this
> facility.
> 
> Ok.  I certainly support a conservative approach!
> 
> But I must say, my feeling is that if you ever encrypt 2^32 session keys
> under the same KEK, "birthday"-style weaknesses will be in the noise:
> you'll be in far-deeper trouble, because that KEK will start to look like
> an awfully fat target.
> In this scenario, I don't think the adversary is going to bother attacking
> the crypto (especially when this only divulges partial information about
> two session keys).
> Instead, he'll go after your KEK by other means (bribe your cleaning
> service
> to Trojan your computer, suck signal off the power lines, send a TEMPEST
> van in your direction, break in to your computer, social engineer his way
> into your secure facility, take a job at your company as a janitor, etc.)
> 
> The right defense is to refresh your KEK's more frequently.  (For
> instance,
> IPSEC expires keys based not just on time but also on # of blocks
> encrypted.)
> I'd argue that this is just prudent cryptographic hygiene.  And once you
> do
> this, the cryptanalytic attacks go away.
> 
> 
> Taking this up a level, my initial reaction is that ietf-smime is
> optimizing
> for the wrong quantity.
> 
> Maximizing the number of session keys you can encrypt under the same KEK
> is a second-order concern.  It seems much more important to try really
> hard
> to reduce the risk that someone finds a subtle bug in your protocol.
> 
> (And, if what I've heard is correct, subtle protocol properties are
> exactly
> the reason ietf-smime is devoting so much effort to key wrapping
> techniques.)
> 
> If you accept this, then the complicated constructions proposed earlier
> may be exactly the wrong way to go; simplicity is arguably the most
> crucial
> quantity to optimize for.
> (And some provable security results can't hurt, either.)
> 
> 
> (Of course, simplicity is only a heuristic.  For instance, Boyko's recent
> results on all-or-nothing transforms look very promising, and deserve more
> investigation.  Even though the construction is not quite as simple as
> e.g.
> encrypt-and-MAC, provable security results are a great way to reduce the
> risk of subtle protocol failures.
> [One warning is that the proofs depend on the "random oracle" model and
> thus do not necessarily transfer to real-world scenarios -- but they are
> still very useful as validation that the basic approach is likely to be
> sound.])
> 
> >  Second, given more time a cryptanalyst might find a better attack.  I
> do
> > not like to start a standard's life with known flaws.
> 
> Yes.  This is a very good point, and normally this would be a very telling
> criticism.  There's a saying: "attacks always get better".
> 
> However, I feel that this case is different.  Remember, Kaliski's attack
> (did I get the author right?) meets the proven lower bounds on security
> very closely.  I would argue that in fact the existence of the attack
> should reassure us that the proofs of security were on the right track,
> rather than raising concerns that better attacks might be "out there".
> 
> > I hope that others on this list will respond to your proposal.
> 
> Me too...  As a newbie to ietf-smime, I would definitely welcome feedback
> (and/or criticism: even "you have no clue, go away!")...
> 
> 
> 
> 

Date: Thu, 18 Feb 1999 15:08:08 +0000
From: Hilton Day <[email-masked]>
Organization: JCP Computer Services
To: [email-masked]
Subject: Selecting key-management algorithm...
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msAB6144F410EE787C0E198603
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

What (if anything) denotes whether a CMS message should use KA or KT as the
key-management algorithm?

I've looked through the spec, and can't see anything which mandates a method for
doing this, so I can only assume it is an implementation-specific choice (i.e.
User-input, or the programmers decide when writing the mail client, based on
security policy).

This leaves me wondering why KA is a "must" for the CMS - it is conveivable that
KA would never be used within the context of S/MIME, as mail clients could simply
use KT to wrap their CEK's.

Ok - I realise that in the interests of interoperability, KA should be implemented
in order that a recipient can read a mail sent with a shared-secret-based key, but
in the same way as Symmetric Key-Encryption Key algorithms are a "may", surely
this is something for the implementor to decide?

I realise that, as I've only been following the spec. since CMS-09, I've probably
already missed conversations along these lines, in which case, apologies to all
those who've hashed over this - but I'd appreciate an explanation.. :-)

Thanks,

Hilton.

--
JCP Computer Services           Tel:    +44 (0) 171 689 6890
16 St Johns Lane,               Fax:    +44 (0) 171 689 0438
London,                         E-Mail: [email-masked]
EC1M 4BS                        WWW:    http://www.jcp.co.uk
United Kingdom

--------------msAB6144F410EE787C0E198603
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msAB6144F410EE787C0E198603--

To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Comments on x942-05 draft
From: EKR <[email-masked]>
Date: 17 Feb 1999 14:19:10 -0800
Lines: 29
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

> John said:
> >> In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m MUST
> >> be >= 160 bits in length". Later in the paragraph, is 160 bits intended as
> >> the appropriate minimum length for p?  (Note, by comparison, that X9.42
> >> requires a multiple of 256 bits with a minimum of 512.)
> 
> Then Eric replied:
> >I'd prefer 160. 512 seems like overkill, and has unpleasant performance
> >tradeoffs.
> 
> I do not have a problem allowing people to have 512-bit private keys.  The
> performance impact is imposed on themselves.  I also think that we should
> permit 160-bit private keys for those people that belive 80-bit security is
> useful.
> 
> In summary, I think that we should allow private keys to be between 160 and
> 512 bits.
That's no problem, but John indicates that X9.42 has a MINIMUM of 512,
which I consider unacceptable.

As far as I'm concerned people should be allowed to go up to |p|

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

Date: Wed, 17 Feb 1999 17:16:51 -0500
To: EKR <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on x942-05 draft
Cc: [email-masked], [email-masked]
Sender: [email-masked]

John said:
>> In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m MUST
>> be >= 160 bits in length". Later in the paragraph, is 160 bits intended as
>> the appropriate minimum length for p?  (Note, by comparison, that X9.42
>> requires a multiple of 256 bits with a minimum of 512.)

Then Eric replied:
>I'd prefer 160. 512 seems like overkill, and has unpleasant performance
>tradeoffs.

I do not have a problem allowing people to have 512-bit private keys.  The
performance impact is imposed on themselves.  I also think that we should
permit 160-bit private keys for those people that belive 80-bit security is
useful.

In summary, I think that we should allow private keys to be between 160 and
512 bits.

Russ

To: "Linn, John" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Comments on x942-05 draft
From: EKR <[email-masked]>
Date: 17 Feb 1999 11:09:50 -0800
Lines: 80
Sender: [email-masked]

"Linn, John" <[email-masked]> writes:
> In sec. 2.1.2, description of "algorithm": suggest adding the following
> sentence at end: "As an implication, it may be appropriate for algorithms
> employing variable parameters other than key size to be represented with
> different OIDs corresponding to different parameter combinations, if
> parameter values cannot be unambiguously determined from usage context".  As
> a related point, would it be acceptable to state that the structure of
> suppPubInfo may be defined on a per-algorithm basis?   For the case of RC2
> usage in S/MIME, where the key length is fixed to 128 bits, it seems to
> offer more protective value to represent the variable effective key length
> within suppPubInfo than to represent the fixed 128 bit length. 
Is this necessary? The simple partition attack obviously doesn't work.
Given knowledge about the 40-bit "effective key" generated by a given
128 bit key, do you get information about the 128-bit "effective key"
that would be generated?

> In 2.1.2, last paragraph, suggest rewriting "the security of the data is
> limited ... even if a string longer than ZZ is generated" as "even if a
> string longer than ZZ is generated, the effective key space of the KEK is
> limited by the size of ZZ, in addition to any security level considerations
> imposed by the parameters p and q."
I have no problem with this.

> In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m MUST
> be >= 160 bits in length". Later in the paragraph, is 160 bits intended as
> the appropriate minimum length for p?  (Note, by comparison, that X9.42
> requires a multiple of 256 bits with a minimum of 512.)
I'd prefer 160. 512 seems like overkill, and has unpleasant performance
tradeoffs.

> In 2.3 and 2.4, suggest adding references to [LL97] for discussion of
> additional means for generating keys which are not subject to small subgroup
> attacks. 
I have no problem with this.

> In the last paragraph of security considerations, suggest rewriting in terms
> of security levels provided, rather than key sizes required. This makes the
> discussion more relevant to particular key sizes selected, rather than
> imposing recommended key sizes. In particular, suggest:
> 
> The security level provided by these methods depends on several factors. It
> depends on the length of the symmetric key (typically, a 2^l security level
> if the length is l bits); the size of the prime q (a 2^{m/2} security
> level); and the size of the prime p (where the security level grows as  a
> subexponential function of the size in bits). A good design principle is to
> have a balanced system, where all three security levels are approximately
> the same. If many keys are derived from a given pair of primes p and q, it
> may be prudent to have higher levels for the primes. In any case, the
> overall security is limited by the lowest of the three levels.
All right.

> Editorial:
> 
> In 2.1.1, the description of h says "... h(p-1)/q mod p ..."; should be "...
> h^{(p-1)/q} mod p ...".
Fine.

> In 2.2, first paragraph, FIPS-186-1 is cited as [DSS], which doesn't appear
> in the references. Given that FIPS-186-1 is currently in a review comment
> period, it may be appropriate to shift this citation to point to the
> finalized [FIPS-186], as included in the references section. 
Agreed.

>  In the same
> paragraph, there's an unmatched opening parenthesis. 
I'll fix it.

> In 2.2, 2nd paragraph, "... consequently, q MUST each be ..." -> "...
> consequently, q MUST be ...".
I'll fix it.

> Sec. 2.4 and the security considerations section each have cross-references
> as "S" rather than "Section". 
Agreed.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

Date: Tue, 16 Feb 1999 11:24:56 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

All:

As the open and public debate continues, I see no one supporting the second
approach described in my 7 Feb 1999 message.  I think we can abandon that
approach, leaving two approaches to Triple-DES key wrapping.  Changes
(hopefully they are improvements) have been suggested for both remaining
approaches.  In this note, I list two updated approaches that are still being
considered.  To keep this note short, I have omitted the unwrap algorithm
description.  The double encryption approach has a shorter result, but the
OAEP-based approach has the all-or-nothing-transform (AONT) property that seems
quite useful.

A MAC-and-Encrypt alternative was suggested.  I am not willing to pursue this
approach due a potential patent issue.  For people who are interested, see
Patent Number 5,673,319.

The S/MIME v3 specifications will include the selected Triple-DES key wrap
algorithm as well as a variant for wrapping RC2 keys (40-128 bit keys).

Please review the algorithms.  Please do not propose improvements that are
covered by any issued or pending patents.

I would like to hear from anyone who has a preference regarding these two
alternatives.

Thanks for your assistance,
  Russ

= = = = = = = = = = 

WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION

Key Checksum

The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value.  The algorithm is:

1.  Compute a 20 octet SHA-1 message digest on the 
    content-encryption key.
2.  Use the most significant (first) eight octets of the 
    message digest value as the checksum value.

Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key, call the result CEK.
2.  Compute a 8 octet key checksum value on CEK as described above,
    call the result ICV.
3.  Let CEKICV = CEK || ICV.
4.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
    an IV of 0xc302e3c1ad8bb738.
5.  Reverse the order of the ciphertext octets.  That is, the most
    significant (first) octet is swapped with the least significant
    (last) octet, and so on.  Call the result TEMP.
6.  Encrypt TEMP in CBC mode using the key-encryption key.  Use 
    an IV of 0x61a197e5b132e196.  The ciphertext is 32 octets long.

WRAP ALOGRITHM #2:  MASK AND ENCRYPT

This algorithm is no longer being considered.

WRAP ALOGRITHM #3:  OAEP AND ENCRYPT

Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key, call the result CEK.
2.  Let CEKPAD = 0x18 || CEK || 0x0000000000000000000000.
3.  Generate a 160-bit random value, called RAND.
4.  Let H1 = SHA-1 ( RAND ).
5.  Let H2 = SHA-1 ( H1 ).
6.  Let MASK1 equal the most significant (first) 36 octets of H2 || H1.
7.  Let MKEY = CEKPAD XOR MASK1.
8.  Let MASK2 = SHA-1 ( MKEY ).
9.  Let MRAND = MASK2 XOR RAND.
10. Let MDATA = MRAND || MKEY.
11. Encrypt MDATA in CBC mode using the key-encryption key.  Use 
    an IV of 0x61a197e5b132e196.  The ciphertext is 56 octets long.

From: "Don Johnson" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 16 Feb 1999 21:37:09 -0500
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Just for the record, text attacks such as Burt mentioned were discussed by
Coppersmith, Johnson and Matyas in their paper on CBCM mode of Triple DES
as a justification for considering it in ANSI X9.  They might have been
known before that, but the ref in the HAC is to that paper, so I know of no
earlier ref.

Don J.

"Bob Jueneman" <[email-masked]> on 02/16/99 08:53:37 PM

To:   [email-masked], [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked] (bcc: Don Johnson/Certicom)
Subject:  Re: A New Triple-DES Key Wrap Algorithm

David,

The reason why I got interested in this subject at all was that I realized
that within
Novell's cryptographic architecture we wrap all sorts of keys, and when a
possible
attack was pointed out I became concerned.

I understand Russ Housley's point about wanting to solve this problem for
S/MIME --
that is his charter, and he wants to deliver a product.  Admirable
dedication.  And I
certainly agree with you that there are other, probably more effective ways
to
compromise S/MIME. than by mailing a billion keys around!

But as a vendor, I don't want to have to solve the key wrapping problem one
way
for S/MIME, plus N other ways for the next N protocols to come along.

Believe me, it is very tough to get the attention of the real experts in
this area,
and so once the problem was raised, I think we should solve it as best we
can,
once and for all. The S/MIME spec will then make a convenient point of
reference
for something that was done right.

For that reason, then, I would tend to dismiss any and all arguments about
whether
some particular attack might or might not be feasible in an S/MIME context
-- that type of
subtlety is exceedingly hard to get right, and besides I want a more
general purpose
solution.

Although Steve Kent's argument about the cost of changing keys often is
quite valid,
your argument about wanting to refresh your KEKs more often is NOT
necessarily
the way to improve security. It depends upon the threat.

Most approaches to brute force attacks try to speed up the number of key
search
operations that can be done simultaneously or in parallel, e.g., the recent
success
at the RSA conference of the EFF's Deep Crack engine in combination with
lots of
distributed computers, all working on the same challenge cipher.

But there is another approach, which I call the vacuum cleaner technique,
where you
don't target any specific key, but rather you suck up million or billions
of keys and
process all of them simultaneously. With this approach, for every new key
that is
tried, either singly or in parallel, the attacker looks at billions of
ciphertexts to see
if the result of encrypting a chosen plaintext with a given key matches any
one of the
ciphertexts that have been collected. (This assumes a chosen plaintext
attack is
feasible, which is the usual conservative assumption.)  In other words,
don't look for
a needle in a haystack -- take the entire haystack.

After all, if I am trying to steal credit card numbers, I don't care much
whose credit card it is --
I'm not trying to target Bill Gates or Donald Trump specifically -- I'll
settle for yours or
almost anybody else's.

In this scenario, increasing the number of KEKs that are used actually
_increases_
my chances of success, for it gives me that many more ciphertext examples
to look at,
assuming that success is measured in terms of how many keys are cracked in
a
given amount of time, rather than how long it takes to crack a specific
key.

Bob

>>> David Wagner <[email-masked]> 02/15/99 03:42PM >>>
> David:
>
> I had the same reaction to the 4 billion wrapped keys; however, there are
> two reasons why we should address this issue.  First, when mail list keys
> are used, the same KEK is used to encrypt CEKs for every message sent to
> the mail list.  Depending on the activity on the mail list ad the
> cryptoperiod of the KEK, the 4 billion wrapped keys might actually
happen,
> especially if severs ever communicated with each other using this
facility.

Ok.  I certainly support a conservative approach!

But I must say, my feeling is that if you ever encrypt 2^32 session keys
under the same KEK, "birthday"-style weaknesses will be in the noise:
you'll be in far-deeper trouble, because that KEK will start to look like
an awfully fat target.
In this scenario, I don't think the adversary is going to bother attacking
the crypto (especially when this only divulges partial information about
two session keys).
Instead, he'll go after your KEK by other means (bribe your cleaning
service
to Trojan your computer, suck signal off the power lines, send a TEMPEST
van in your direction, break in to your computer, social engineer his way
into your secure facility, take a job at your company as a janitor, etc.)

The right defense is to refresh your KEK's more frequently.  (For instance,
IPSEC expires keys based not just on time but also on # of blocks
encrypted.)
I'd argue that this is just prudent cryptographic hygiene.  And once you do
this, the cryptanalytic attacks go away.

Taking this up a level, my initial reaction is that ietf-smime is
optimizing
for the wrong quantity.

Maximizing the number of session keys you can encrypt under the same KEK
is a second-order concern.  It seems much more important to try really hard
to reduce the risk that someone finds a subtle bug in your protocol.

(And, if what I've heard is correct, subtle protocol properties are exactly
the reason ietf-smime is devoting so much effort to key wrapping
techniques.)

If you accept this, then the complicated constructions proposed earlier
may be exactly the wrong way to go; simplicity is arguably the most crucial
quantity to optimize for.
(And some provable security results can't hurt, either.)

(Of course, simplicity is only a heuristic.  For instance, Boyko's recent
results on all-or-nothing transforms look very promising, and deserve more
investigation.  Even though the construction is not quite as simple as e.g.
encrypt-and-MAC, provable security results are a great way to reduce the
risk of subtle protocol failures.
[One warning is that the proofs depend on the "random oracle" model and
thus do not necessarily transfer to real-world scenarios -- but they are
still very useful as validation that the basic approach is likely to be
sound.])

>  Second, given more time a cryptanalyst might find a better attack.  I do
> not like to start a standard's life with known flaws.

Yes.  This is a very good point, and normally this would be a very telling
criticism.  There's a saying: "attacks always get better".

However, I feel that this case is different.  Remember, Kaliski's attack
(did I get the author right?) meets the proven lower bounds on security
very closely.  I would argue that in fact the existence of the attack
should reassure us that the proofs of security were on the right track,
rather than raising concerns that better attacks might be "out there".

> I hope that others on this list will respond to your proposal.

Me too...  As a newbie to ietf-smime, I would definitely welcome feedback
(and/or criticism: even "you have no clue, go away!")...

Date: Tue, 16 Feb 1999 18:53:37 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

David,

The reason why I got interested in this subject at all was that I realized that within
Novell's cryptographic architecture we wrap all sorts of keys, and when a possible 
attack was pointed out I became concerned.

I understand Russ Housley's point about wanting to solve this problem for S/MIME --
that is his charter, and he wants to deliver a product.  Admirable dedication.  And I 
certainly agree with you that there are other, probably more effective ways to 
compromise S/MIME. than by mailing a billion keys around!

But as a vendor, I don't want to have to solve the key wrapping problem one way 
for S/MIME, plus N other ways for the next N protocols to come along.

Believe me, it is very tough to get the attention of the real experts in this area,
and so once the problem was raised, I think we should solve it as best we can, 
once and for all. The S/MIME spec will then make a convenient point of reference
for something that was done right.

For that reason, then, I would tend to dismiss any and all arguments about whether
some particular attack might or might not be feasible in an S/MIME context -- that type of
subtlety is exceedingly hard to get right, and besides I want a more general purpose 
solution.

Although Steve Kent's argument about the cost of changing keys often is quite valid,
your argument about wanting to refresh your KEKs more often is NOT necessarily 
the way to improve security. It depends upon the threat.

Most approaches to brute force attacks try to speed up the number of key search 
operations that can be done simultaneously or in parallel, e.g., the recent success 
at the RSA conference of the EFF's Deep Crack engine in combination with lots of 
distributed computers, all working on the same challenge cipher.

But there is another approach, which I call the vacuum cleaner technique, where you 
don't target any specific key, but rather you suck up million or billions of keys and 
process all of them simultaneously. With this approach, for every new key that is 
tried, either singly or in parallel, the attacker looks at billions of ciphertexts to see 
if the result of encrypting a chosen plaintext with a given key matches any one of the 
ciphertexts that have been collected. (This assumes a chosen plaintext attack is 
feasible, which is the usual conservative assumption.)  In other words, don't look for 
a needle in a haystack -- take the entire haystack.

After all, if I am trying to steal credit card numbers, I don't care much whose credit card it is --
I'm not trying to target Bill Gates or Donald Trump specifically -- I'll settle for yours or 
almost anybody else's.

In this scenario, increasing the number of KEKs that are used actually _increases_ 
my chances of success, for it gives me that many more ciphertext examples to look at,
assuming that success is measured in terms of how many keys are cracked in a
given amount of time, rather than how long it takes to crack a specific key.

Bob

>>> David Wagner <[email-masked]> 02/15/99 03:42PM >>>
> David:
> 
> I had the same reaction to the 4 billion wrapped keys; however, there are
> two reasons why we should address this issue.  First, when mail list keys
> are used, the same KEK is used to encrypt CEKs for every message sent to
> the mail list.  Depending on the activity on the mail list ad the
> cryptoperiod of the KEK, the 4 billion wrapped keys might actually happen,
> especially if severs ever communicated with each other using this facility.

Ok.  I certainly support a conservative approach!

But I must say, my feeling is that if you ever encrypt 2^32 session keys
under the same KEK, "birthday"-style weaknesses will be in the noise:
you'll be in far-deeper trouble, because that KEK will start to look like
an awfully fat target.
In this scenario, I don't think the adversary is going to bother attacking
the crypto (especially when this only divulges partial information about
two session keys).
Instead, he'll go after your KEK by other means (bribe your cleaning service
to Trojan your computer, suck signal off the power lines, send a TEMPEST
van in your direction, break in to your computer, social engineer his way
into your secure facility, take a job at your company as a janitor, etc.)

The right defense is to refresh your KEK's more frequently.  (For instance,
IPSEC expires keys based not just on time but also on # of blocks encrypted.)
I'd argue that this is just prudent cryptographic hygiene.  And once you do
this, the cryptanalytic attacks go away.

Taking this up a level, my initial reaction is that ietf-smime is optimizing
for the wrong quantity.

Maximizing the number of session keys you can encrypt under the same KEK
is a second-order concern.  It seems much more important to try really hard
to reduce the risk that someone finds a subtle bug in your protocol.

(And, if what I've heard is correct, subtle protocol properties are exactly
the reason ietf-smime is devoting so much effort to key wrapping techniques.)

If you accept this, then the complicated constructions proposed earlier
may be exactly the wrong way to go; simplicity is arguably the most crucial
quantity to optimize for.
(And some provable security results can't hurt, either.)

(Of course, simplicity is only a heuristic.  For instance, Boyko's recent
results on all-or-nothing transforms look very promising, and deserve more
investigation.  Even though the construction is not quite as simple as e.g.
encrypt-and-MAC, provable security results are a great way to reduce the
risk of subtle protocol failures.
[One warning is that the proofs depend on the "random oracle" model and
thus do not necessarily transfer to real-world scenarios -- but they are
still very useful as validation that the basic approach is likely to be
sound.])

>  Second, given more time a cryptanalyst might find a better attack.  I do
> not like to start a standard's life with known flaws.

Yes.  This is a very good point, and normally this would be a very telling
criticism.  There's a saying: "attacks always get better".

However, I feel that this case is different.  Remember, Kaliski's attack
(did I get the author right?) meets the proven lower bounds on security
very closely.  I would argue that in fact the existence of the attack
should reassure us that the proofs of security were on the right track,
rather than raising concerns that better attacks might be "out there".

> I hope that others on this list will respond to your proposal.

Me too...  As a newbie to ietf-smime, I would definitely welcome feedback
(and/or criticism: even "you have no clue, go away!")...

Date: Tue, 16 Feb 1999 18:19:54 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Good enough, although I think there are potential cryptographic 
advantages to reversing the byte order as well.

Bob

>>> Russ Housley <[email-masked]> 02/15/99 07:57AM >>>
Swapping the bytes and swapping the blocks would have the same impact as
far as I can tell.  Swapping bytes is probably easier to code, so I accpt
this improvement.

Russ

/15/99 +0000, Peter Gutmann wrote:
>Russ Housley <[email-masked]> writes:
> 
>>5.  Reverse the order of the four ciphertext blocks.
> 
>Wouldn't it be better to reverse the bytes rather than the blocks?  This
makes 
>the result independant of the block size of the algorithm (so it'll work with 
>CFB mode as well), and it's rather easier to code than shuffling chunks of 
>memory around.
> 
>Peter.
>

Date: Tue, 16 Feb 1999 14:49:34 -0500
To: David Wagner <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

David,

The particular heavy use of the KEK that Russ cited is a side effect of the
mailing list key management approach adopted by MSP, and later by S/MIME.
It is driven by a strong desire to NOT distribute KEKs more frequently, or
on a piecemeal basis, because of the costs of doing so.  So, in this case,
I think we just have to live with this as a problem constraint for the
S/MIME environment.  However, I agree that there may be lots of better ways
to go after the KEK in these instances, givens its widespread distribution.

steve

Date: Tue, 16 Feb 1999 11:21:39 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: S-MIME / IETF <[email-masked]>
CC: Hans Nilsson <[email-masked]>
Subject: Validation of Electronic Signatures
Sender: [email-masked]

The validation of Electronic Signatures poses several difficult and
interesting problems, in particular when it is necessary to validate
an Electronic signature for example 20 years later, when the signer
key has been compromised and revoked, the CA keys have been
compromised, the crypto algorithm or key length used at the
signature time is no longer secure, and the hash function
used at at the signature time now exhibits message collisions.

The validation problem changes over the different time frames:
- near term, when all involved certificates are still valid and
  generally available,
- long term, when one or more of the involved certificates have expired,
- archival, when the initial cryptography used is no longer secure.

Another interesting point to consider is how it is possible to know and
trust the signing time as indicated by the signer.

A "white paper" dealing with these kinds of situations has been written and
demonstrates the use of time-stamping.

This paper can serve as a tutorial to this difficult subject, but also as
input for the discussion of a common validation model for electronic
signatures. The paper can be found at the following addresses:

http://www.openmaster.com/whitepapers/es_validation.pdf
http://www.id2tech.com/news/pdf/ES_validation.pdf

Denis Pinkas

From: David Wagner <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
To: [email-masked]
Date: Mon, 15 Feb 1999 14:42:01 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> David:
> 
> I had the same reaction to the 4 billion wrapped keys; however, there are
> two reasons why we should address this issue.  First, when mail list keys
> are used, the same KEK is used to encrypt CEKs for every message sent to
> the mail list.  Depending on the activity on the mail list ad the
> cryptoperiod of the KEK, the 4 billion wrapped keys might actually happen,
> especially if severs ever communicated with each other using this facility.

Ok.  I certainly support a conservative approach!

But I must say, my feeling is that if you ever encrypt 2^32 session keys
under the same KEK, "birthday"-style weaknesses will be in the noise:
you'll be in far-deeper trouble, because that KEK will start to look like
an awfully fat target.
In this scenario, I don't think the adversary is going to bother attacking
the crypto (especially when this only divulges partial information about
two session keys).
Instead, he'll go after your KEK by other means (bribe your cleaning service
to Trojan your computer, suck signal off the power lines, send a TEMPEST
van in your direction, break in to your computer, social engineer his way
into your secure facility, take a job at your company as a janitor, etc.)

The right defense is to refresh your KEK's more frequently.  (For instance,
IPSEC expires keys based not just on time but also on # of blocks encrypted.)
I'd argue that this is just prudent cryptographic hygiene.  And once you do
this, the cryptanalytic attacks go away.

Taking this up a level, my initial reaction is that ietf-smime is optimizing
for the wrong quantity.

Maximizing the number of session keys you can encrypt under the same KEK
is a second-order concern.  It seems much more important to try really hard
to reduce the risk that someone finds a subtle bug in your protocol.

(And, if what I've heard is correct, subtle protocol properties are exactly
the reason ietf-smime is devoting so much effort to key wrapping techniques.)

If you accept this, then the complicated constructions proposed earlier
may be exactly the wrong way to go; simplicity is arguably the most crucial
quantity to optimize for.
(And some provable security results can't hurt, either.)

(Of course, simplicity is only a heuristic.  For instance, Boyko's recent
results on all-or-nothing transforms look very promising, and deserve more
investigation.  Even though the construction is not quite as simple as e.g.
encrypt-and-MAC, provable security results are a great way to reduce the
risk of subtle protocol failures.
[One warning is that the proofs depend on the "random oracle" model and
thus do not necessarily transfer to real-world scenarios -- but they are
still very useful as validation that the basic approach is likely to be
sound.])

>  Second, given more time a cryptanalyst might find a better attack.  I do
> not like to start a standard's life with known flaws.

Yes.  This is a very good point, and normally this would be a very telling
criticism.  There's a saying: "attacks always get better".

However, I feel that this case is different.  Remember, Kaliski's attack
(did I get the author right?) meets the proven lower bounds on security
very closely.  I would argue that in fact the existence of the attack
should reassure us that the proofs of security were on the right track,
rather than raising concerns that better attacks might be "out there".

> I hope that others on this list will respond to your proposal.

Me too...  As a newbie to ietf-smime, I would definitely welcome feedback
(and/or criticism: even "you have no clue, go away!")...

Date: Mon, 15 Feb 1999 09:57:32 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked]
Sender: [email-masked]

Swapping the bytes and swapping the blocks would have the same impact as
far as I can tell.  Swapping bytes is probably easier to code, so I accpt
this improvement.

Russ

/15/99 +0000, Peter Gutmann wrote:
>Russ Housley <[email-masked]> writes:
> 
>>5.  Reverse the order of the four ciphertext blocks.
> 
>Wouldn't it be better to reverse the bytes rather than the blocks?  This
makes 
>the result independant of the block size of the algorithm (so it'll work with 
>CFB mode as well), and it's rather easier to code than shuffling chunks of 
>memory around.
> 
>Peter.
>

Date: Mon, 15 Feb 1999 09:03:17 -0500
To: Burt Kaliski <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Burt:

Thanks for the pointer.  I found the article very interesting.  I did not
try to comprehend the proofs, but I found the AONT discussion very useful.

Has the double-encryption approach that we are considering been analyzed as
an AONT?  If so, how does it stack up when compared to OAEP?

Russ

At 10:52 AM 2/12/99 -0800, Burt Kaliski wrote:
>FYI, Victor Boyko has just posted his research results showing how OAEP
>enhances the security of symmetric encryption. See
>http://theory.lcs.mit.edu/~boyko/aont-oaep.html.
>
>-- Burt

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: A New Triple-DES Key Wrap Algorithm
Reply-To: [email-masked]
Date: Mon, 15 Feb 1999 04:14:01 (NZDT)
Sender: [email-masked]

Russ Housley <[email-masked]> writes:
 
>5.  Reverse the order of the four ciphertext blocks.
 
Wouldn't it be better to reverse the bytes rather than the blocks?  This makes 
the result independant of the block size of the algorithm (so it'll work with 
CFB mode as well), and it's rather easier to code than shuffling chunks of 
memory around.
 
Peter.

Date: Fri, 12 Feb 1999 13:00:10 -0500
To: Hilton Day <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: [Q] Key-Agreement?
Cc: [email-masked]
Sender: [email-masked]

Hilton:

RSA is a key transport algorithm, and Diffie-Hellman is a key agreement
algorithm.

With RSA, the originator needs the recipient's public key (from the
recipient's certificate).  The CEK is encrypted in the recipient's public
key.  The recipient does not a certificate or public key from the
originator to decrypt the CEK -- the originator only needs his own private key.

With Diffie-Hellman.the originator uses the recipient's public key and his
own private key to create a KEK.  The CEK is then encrypted in the KEK.
For the recipient to form the same KEK, the originator's public key and the
recipient's private key are used.  So, the CMS RecipientInfo structure
permits the originator to send the one-time public key in the message.

I hope this is the level of information you were seeking.

Russ

At 04:18 PM 2/12/99 +0000, Hilton Day wrote:
>Hi all,
>
>I've been following the S/MIME 3 spec. since late in CMS-09, and am curious
>about the Key Agreement Key Management Algorithm, and it's purpose within the
>specification...
>
>What purpose does using Key Agreement serve, rather than just using basic the
>Key Transport mechanism?
>
>I've had a look through the CMS (10), and it isn't clear what are the merit's
>(or not) of using KA vs. KT.
>
>Thanks in advance,
>
>Hilton.
>
>[PS - replies to either me directly, or ietf-smime mailing list (depending on
>how useful you think the reply is to others) - I subscribe, so either way I'll
>get the response]
>
>--
>JCP Computer Services           Tel:    +44 (0) 171 689 6890
>16 St Johns Lane,               Fax:    +44 (0) 171 689 0438
>London,                         E-Mail: [email-masked]
>EC1M 4BS                        WWW:    http://www.jcp.co.uk
>United Kingdom
>
>

Date: Fri, 12 Feb 1999 16:18:28 +0000
From: Hilton Day <[email-masked]>
Organization: JCP Computer Services
To: [email-masked]
Subject: [Q] Key-Agreement?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms63E3498BA058893F8D97457C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

I've been following the S/MIME 3 spec. since late in CMS-09, and am curious
about the Key Agreement Key Management Algorithm, and it's purpose within the
specification...

What purpose does using Key Agreement serve, rather than just using basic the
Key Transport mechanism?

I've had a look through the CMS (10), and it isn't clear what are the merit's
(or not) of using KA vs. KT.

Thanks in advance,

Hilton.

[PS - replies to either me directly, or ietf-smime mailing list (depending on
how useful you think the reply is to others) - I subscribe, so either way I'll
get the response]

--
JCP Computer Services           Tel:    +44 (0) 171 689 6890
16 St Johns Lane,               Fax:    +44 (0) 171 689 0438
London,                         E-Mail: [email-masked]
EC1M 4BS                        WWW:    http://www.jcp.co.uk
United Kingdom

--------------ms63E3498BA058893F8D97457C
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms63E3498BA058893F8D97457C--

From: "Snow, Brian D." <[email-masked]>
To: Carl Ellison <[email-masked]>, Russ Housley <[email-masked]>
Cc: acc <[email-masked]>, ams <[email-masked]>, balenson <[email-masked]>, benaloh <[email-masked]>, berson <[email-masked]>, bfox <[email-masked]>, Bob Jueneman <[email-masked]>, "Blake.greenlee" <[email-masked]>, brickell <[email-masked]>, bschanni <[email-masked]>, burt <[email-masked]>
Cc: "carlisle.adams" <[email-masked]>, cjwagne <[email-masked]>, daw <[email-masked]>, denning <[email-masked]>, denny <[email-masked]>, desmedt <[email-masked]>, dickie <[email-masked]>, djohnson <[email-masked]>, ekr <[email-masked]>, ietf-smime <[email-masked]>, jhs <[email-masked]>
Cc: jis <[email-masked]>, jlinn <[email-masked]>, kent <[email-masked]>, merkle <[email-masked]>, mhetzel <[email-masked]>, omura <[email-masked]>, paulv <[email-masked]>, pcain <[email-masked]>, rivest <[email-masked]>, schneier <[email-masked]>, smatyas <[email-masked]>, smid <[email-masked]>
Cc: "TACAR.PRV-7.PROVO" <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Date: Wed, 10 Feb 99 10:54:00 PST
Sender: [email-masked]

Gents,

     Just a minor side observation;
     
     Yes, zero is easy to get right in a standard; but not as easy
 to TEST if an implementation is correct during debug stage...
a fixed non-symmetric pattern detects early-on big-endian vrs little-endian
problems and other such problems encountered by developers.
However, other tests nail that down as well, so no big deal.

This is not a request for a change, just a side-observation.

Brian Snow

 ----------
From: Carl Ellison
To: Russ Housley
Cc: Bob Jueneman; ietf-smime; cme; berson; bschanni; kent; pcain; mhetzel; 
brickell; djohnson; schneier; daw; denning; smid; omura; carlisle.adams; 
paulv; Blake.greenlee; benaloh; bfox; cjwagne; jis; TACAR.PRV-7.PROVO; 
merkle; BSnow; burt; ekr; jlinn; ams; rivest; balenson; denny; acc; jhs; 
dickie; smatyas; desmedt
Subject: Re: A New Triple-DES Key Wrap Algorithm
Date: Tuesday, February 09, 1999 11:26PM

 -----BEGIN PGP SIGNED MESSAGE-----

At 11:31 AM 2/9/99 -0500, Russ Housley wrote:
>[RH] Two different IVs is easy.  The zero IVs were suggested by Carl
Ellison.

That's because one constant IV is as good as another, IMHO, and zero is a
lot easier to get right in a standard.

 -----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQCVAwUBNsE0uxN3Wx8QwqUtAQG+oQP8D8foR8OQ/R7/ryV1rXfsKindHItavGlN
p18kDFpgsrS2yl9HrGdGSwf+t3vEvfLVNGGHEYg96F6QgsBSoo83ZgEDm5na25hk
fJfp8xipoApdPTKw8czwigoOAcujhx73T34JzgRIllWeLbH1mK77HgAiFH6oy4K0
Cn1u9Yc7Tmc=
=7Mu2
 -----END PGP SIGNATURE-----

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     http://www.pobox.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

Date: Tue, 09 Feb 1999 23:26:52 -0800
To: Russ Housley <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

At 11:31 AM 2/9/99 -0500, Russ Housley wrote:
>[RH] Two different IVs is easy.  The zero IVs were suggested by Carl Ellison. 

That's because one constant IV is as good as another, IMHO, and zero is a 
lot easier to get right in a standard.

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     http://www.pobox.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

Date: Wed, 10 Feb 1999 01:06:26 +0100
From: Rogier van Wanroij <[email-masked]>
To: [email-masked]
Subject: Implementing S/MIME v3
Sender: [email-masked]

Hello,

Is there a S/MIME v3 (source-code) implementation available outside the US?
And if not would it be (very?) difficult to create a (partly) implementation
of S/MIME v3 from scratch, or by transforming a S/MIME v2 implementation (if
available) to S/MIME v3?
	What tools/libraries are available or would you recommend to use if I wanted
to create a (partly) S/MIME v3 implementation (except for the SNACC ASN.1 +
DER Compiler). Or maybe (hopefully) some parts are all ready written and
available? I very much would appreciate any pointers you might have.

BTW, I am located outside the US (the Netherlands).

Greetings and thank you,

Rogier van Wanroij
([email-masked])

PS.

Excuse me for my bad(?) english, it is not my native tongue

From: William Whyte <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, EKR <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, "Linn, John" <[email-masked]>, "'IETF SMIME list'" <[email-masked]>
Subject: RE: Crypto-oriented comments on x942-04
Date: Tue, 9 Feb 1999 18:10:19 -0000
Organization: Baltimore Technologies
Sender: [email-masked]

Russ, Eric,

[snip...]
> >This is incorrect. By fiat, when used for key encryption, RC2 ALWAYS
> >uses a 128 bit key. The 40 bits refers only to the effective key length.
> >It may be possible to go from the 40 bit key to having some information
> >about the 128 bit key, but it's certainly not as simple as simply
> >knowing the first 40 bits.
> 
> You are correct. We did deal with this case.  However, I think is is a good
> idea to use the algorithm in such a way that future users of CMS cannot
> make a simple mistake and be susceptable to the partion attack.
> 
> >>And, the fix is
> >> very simple.  We need to simply include the key length in the hash input. 
> >I'm prepared to do it, but I'm not sure that just shoving it in the 
> >pubInfo is the right choice. I'll think about this and try to write 
> >up a proposal by monday.
> 
> If you are going to the RSA Confernce, I will gladly have a hallway chat
> regarding the best way forward.

How did the chat end up? I notice that x942-05 ended up "shoving it in 
the pubInfo"; but I also notice that it still specifies that the keylength
is 128 bits for RC2, regardless of what the effective keylength is chosen
to be. This means that regardless of the effective keylength, we produce
the same material for input to the RC2 key expansion function. Have we 
decided that this isn't a weakness? Or should we be using different 
material to produce keys with different effective lengths?

Cheers,

William

Date: Tue, 09 Feb 1999 12:02:16 -0500
To: David Wagner <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

David:

I had the same reaction to the 4 billion wrapped keys; however, there are
two reasons why we should address this issue.  First, when mail list keys
are used, the same KEK is used to encrypt CEKs for every message sent to
the mail list.  Depending on the activity on the mail list ad the
cryptoperiod of the KEK, the 4 billion wrapped keys might actually happen,
especially if severs ever communicated with each other using this facility.
 Second, given more time a cryptanalyst might find a better attack.  I do
not like to start a standard's life with known flaws.

I hope that others on this list will respond to your proposal.

Russ

At 05:26 PM 2/8/99 -0800, David Wagner wrote:
>I don't want to step on any toes, but frankly, I think all three of these
>are much too complicated for S/MIME.  I believe in fighting complexity and
>cryptographic bloat; complexity greatly introduces the potential for
>subtle bugs.
>
>S/MIME doesn't need to worry about encrypting 2^32 CEKs with the same KEK;
>this threat is just off the map, as far as I can tell.  (I've never sent
>2^32 emails in my life, let alone to the same party.  And prudent
>cryptographic practice says you should change your KEK far more often than
>this, anyway...)
>
>I propose a much simpler algorithm.  In fact, it's so simple that it is
>_provably secure_.  (Oooh...)  To me, both of these features seem to greatly
>reduce the risk of surprising weaknesses.
>
>Basic idea:  You already have some shared keying material (KEK).  So just
>MAC the CEK using some shared key material, then encrypt the result using
>more of the shared key material.
>
>For the MAC, you can use SHA1-HMAC.  Secure if SHA1 satisfies some relatively
>plausible cryptographic properties.  See [1].
>(Or usse Triple-DES-CBC-MAC.  Provably secure if Triple-DES is, good for up
>to ~ 2^30 blocks or so.  See [2].)
>
>For encryption, you can use e.g. Triple-DES-CBC.  Provably secure if
>Triple-DES is, good for up to ~ 2^32 blocks or so.  See [3].
>
>You can also prove that the whole scheme (i.e. the composition of the MAC
>and the encryption) is secure (if both components are), if you use independent
>keys.  (Using the same key for the MAC and the encryption is a Bad Idea.)
>In practice, true independent keys are hard to arrive at.  But you can
>just derive as much keying material as you need from your KEK, and get
>keys which are computationally-indistinguishable from random.
>
>Thus, I suggest e.g. expanding the KEK with Triple-DES counter mode as far
>as needed to get a MAC key + an encryption key.  This is also provably secure,
>if Triple-DES is.
>
>Result: a whole scheme which is provably secure if Triple-DES (and maybe
>SHA1) are.  Seems like a potentially useful property to me...
>
>Of course, you have to ask what exactly is "proven" by the provable security
>results.  I claim that as far as I know, the proven security results will
>provide everything you need for S/MIME key wrapping.
>(But since you haven't specified the requirements precisely, or even at all,
>there are no guarantees.  Nonetheless I think the provable security indicates
>strongly that the basic approach is sound and plausible.)
>
>Of course, I'm also coming at this as an outsider, who's only recently started
>tracking the S/MIME stuff, so it's possible I've missed some requirement of
>the application.  But there are enough really sharp people reading this that
>if I made important oversights, I believe someone will call me on it...
>
>Regards,
>-- David
>
>
>[1]  Bellare, Rogaway, Krawczyk, ``Keying hash functions for message
>     authentication'', CRYPTO '96.
>[2]  Bellare, Kilian, Rogaway, ``The security of cipher block chaining'',
>     CRYPTO '94.
>[3]  Bellare, Desai, Jokipii, Rogaway, ``A concrete security treatment
>     of symmetric encryption: analysis of the DES modes of operation,''
>     38th FOCS (1997).
>

Date: Tue, 09 Feb 1999 11:31:55 -0500
To: "Bob Jueneman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Bob Jueneman wrote:
>Russ, nice job of synthesizing various inputs into a standard format.
[RH] Thanks.

>However, I continue to think we have two problems that have to 
>be addressed. One is cryptographic, and one is architectural.
>
>The cryptographic problem is one of not wanting to leak any
>information in the case of many, many wrappings of the same CEK,
>or in the case of a single KEK being used to wrap many, many CEKs;
>where an observation of two matching ciphertexts might reveal information
>about the plaintext if the cipher text includes any form of stereotyped of
>constant information, e.g., parity bits or padding.
[RH] Bob, this a a good summary of the high-level objectives.

>The architectural problem is to try to avoid the forthcoming problem of 
>needing N-squared algorithm IDs in order to handle the various combinations
>of key encryption keys and content encryption keys of different types that
>are likely to be developed over the coming years.  
[RH] Algorithm identifiers are cheap.  The security is much more important
than conserving identifiers.  However, I understand the desire for a
general solution.

>Although S/MIME may only be interested in some small number of algorithm
>types today, there are lots of places where wrapped keys may be required 
>in addition to S/MIME, and as a security architect I don't want to have 
>to keep reinventing (and recoding) key wrapping techniques.
>
>For this reason, I will offer my comments inline on the algorithms that
you have 
>proposed, and then propose a new Generalized Key Wrapping Algorithm
>that attempts to take the best features of each of the three approaches you 
>have described, and apply them in a more generalized way.
>
>In addition, I've tried to explicitly state the security criteria, as I
agree with 
>Don Johnson.  Reasonable men can still differ, but if they don't have a
common 
>understanding and agreement as to the requirements, differences are almost
>guaranteed.
>
>= = = = = = = = = = 
>
>
>WRAP ALGORITHM #1:  DOUBLE ENCRYPTION
>
>A.1  Key Checksum
>
>The CMS Checksum Algorithm is used to provide an content-encryption key
>integrity check value.  The algorithm is:
>
>1.  Compute a 20 octet SHA-1 message digest on the 
>    content-encryption key.
>2.  Use the most significant (first) eight octets of the 
>    message digest value as the checksum value.
>
>[RRJ]  I'm really not convinced of the necessity for a key checksum, although
>I certainly have not followed all of the previous discussion.  If someone
were 
>trying to attack the key distribution mechanism, then the key checksum
>could act as an oracle. I would _much_ prefer to checksum the entire result,
>i.e., the final encrypted  key, than to checksum the CEK itself.  Is there
some 
>strong justification for this that I've missed, such as the French stop-code
>requirement?
[RH] My reason is quite straightforward.  Once the key is unwrapped, it
will be used to decrypt the content.  In many cases, the content will be
rather large.  If an attacker alters the wrapped key, the resulting
upwrapped key will not be the correct CEK.  If there is not an integrity
check on the CEK, then the entire content must be processed.  The resulting
content will be junk, and a fair amount of processing was doen to get that
junk.  I simply want to detect the modification as early in the processing
as possible.

>A.2  Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising 
>    the content-encryption key.
>2.  Compute a 8 octet key checksum value on the content-encryption
>    key as described above.
>3.  Concatenate the key checksum value and the content-encryption key.
>    The result is four 8 octet blocks: B1, B2, B3, and B4.
>4.  Encrypt in CBC mode the four blocks using the key-encryption key.
>    Use an IV of all zeros.
>5.  Reverse the order of the four ciphertext blocks.  The resulting
>    order is B4, B3, B2, and B1.
>
>[RRJ] Rather than merely interchange the order of the four blocks, I believe 
>that the entire string should be reversed, byte for byte. (I'd really like
>to do it bit by bit, but the code would be a little awkward.) Preserving the
>original block boundaries might possibly allow some clever attacks. I also
>don't see the need for the final reversal.  
[RH] I only see one reversal.  Also, Reordering the blocks, bytes or bits
all preserve the block boundaries.  The same ciphertext bits (in different
orders) will comprise the inputs to the second encryption in each case.
>
>6.  Encrypt the four blocks a second time.  Encrypt in CBC mode 
>    using the key-encryption key.  Use an IV of all zeros.
>
>[RRJ]  I would prefer to use something other than 0 for the IV.
>Ideally, the IV should be variable for each KEK, in order to make
>a chosen plaintext attack that much more difficult. If a varying IV is
>too difficult from a protocol standpoint, then at least avoid any kind of 
>repeating structure -- use pi, or the square root of 2, or something
>random.  And use two different IVs for the different steps.
>Tom Berson is absolutely right -- avoid structure and 
>symmetry at all cost!
[RH] Two different IVs is easy.  The zero IVs were suggested by Carl Ellison. 

>[RRJ]  But my primary objection to this approach is the expense incurred
by the 
>second encryption pass. Even though a triple-DES operation may be quite
>fast compared to say an RSA encryption, cycles are cycles, and
>deliberately causing additional key management overhead that could be
>avoided is unacceptable.
[RH] This double encryption operation has the property that every output
bit depends on every input bit.  This is highly desirable.

>WRAP ALGORITHM #2:  MASK AND ENCRYPT
>
>B.1  Key Checksum
>
>The CMS Checksum Algorithm is used to provide an content-encryption key
>integrity check value.  The algorithm is:
>
>1.  Compute a 20 octet SHA-1 message digest on the 
>    content-encryption key.
>2.  Use the most significant (first) eight octets of the 
>    message digest value as the checksum value.
>
>B.2  Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising 
>    the content-encryption key.
>2.  Compute a 8 octet key checksum value on the content-encryption
>    key as described above.
>3.  Generate an 8 octet random number: RAND.
>4.  Let H1 = SHA-1 ( RAND ).
>5.  Let H2 = SHA-1 ( H1 ).
>6.  Let MASK equal the most significant (first) 32 octets of H1 || H2.
>
>[RRJ] H2 is in some sense "more random" than H1, since it includes 
>the mixing effect of the previous SHA-1.  If RAND were less than perfectly
>random, i.e., subject to some kind of bias, H1 might remove most, but perhaps
>not all of the bias, but if SHA-1 is any good at all, H2 should be much
>less likely to leak information. For that reason, and since CBC introduces 
>error propagation in the forward direction, MASK should equal the most 
>significant (first) 32 octets of H2 || H1.
[RH] Fine.

>7.  Let KEYICV equal the content-encryption key concatenated with
>    the key checksum value.
>
>[RRJ] For the reason given above, forward error propagation, the KEYICV should
>be formed by taking the key checksum concatenated with (followed by)
>the CEK.  But I would greatly prefer not to have a key checksum at all, 
>in which case MASK would only be 24 octets long, assuming a "naked" 
>triple-DES CEK.
[RH] Okay.  Let KEYICV equal the key checksum value concatenated with the
content-encryption key.

>8.  Let PLAIN = RAND || ( KEYICV XOR MASK ).
>
>[RRJ] The disadvantage of this approach, as compared to approach 3
>(OAEP), is that the RAND is not whitened. Therefore, if there is any weakness
>in RAND, it may be possible to derive some information from any block that 
>has a matching ciphertext.
[RH] In your posting on 4 Feb 1999, I did not see any whitening of RAND.
This alternative builds on your proposal....

>9.  Encrypt PLAIN in CBC mode using the key-encryption key.
>    Use an IV of all zeros.
>
>
>WRAP ALGORITHM #3:  OAEP AND ENCRYPT
>
>C.1  Key Checksum
>
>No explicit checksum algorism is needed.  The OAEP processing provides 
>the necessary integrity.
>
>C.2  Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising 
>    the content-encryption key, called CEK.
>2.  Let CEKPAD = 0x18 || CEK || 0x0000000000000000000000.
>3.  Generate a 160-bit random value, called RAND.
>4.  Let H1 = SHA-1 ( RAND || 0x01 ).
>5.  Let H2 = SHA-1 ( RAND || 0x02 ).
>6.  Let MASK1 equal the most significant (first) 36 octets of H1 || H2.
>
>[RRJ]  I would prefer that a stronger function than this be used.
>As it stands, the input to the two SHA-1 routines differ by only
>two bits.  Use the approach of scheme 2 as modified above, i.e.,
>Let H1 = SHA-1 ( RAND ),  H2 = SHA-1 ( H1 ) , 
>MASK1 equal the most significant (first) 36 octets of H2 || H1.
[RH] I took this approach from SET.  I have not problem with your suggestion.

>7.  Let MKEY = CEKPAD XOR MASK1.
>8.  Let MASK2 = SHA-1 ( MKEY ).
>9.  Let MRAND = MASK2 XOR RAND.
>10. Let MDATA = MRAND || MKEY.
>11. Encrypt MDATA with the key-encryption key and CBC mode.  Use an IV
>    with each octet equal to 0xA5.  The ciphertext is 56 octets long.
>
>[RRJ]  Again, there is absolutely no reason to deliberately introduce
>structure and symmetry in the IV.  If possible, use a real IV that varies 
>for each KEK, in order to make a chosen plaintext attack that much 
>more difficult.  At a minimum, use a pseudo-random constant with no 
>apparent structure.
[RH] A random IV is fine.  I was trying to avoid an extra block.  We could
accept the extra block or generate a random value and use it as a constant.

>[RRJ]  If these problems were fixed, I believe that Approach 3 would be my 
>favorite of those above, because it seems to be the most secure 
>without introducing an unnecessary second encryption step.
[RH] You seem to agree with Burt Kaliski that OAEP is the correct foundation.
>
>However, I believe we can do better yet. Here is my recommended approach, 
>one that tries to take advantage of all of the tweaks included above.
>
>======================
>
>
>
>GENERALIZED KEY WRAPPING ALGORITHM (Version 1)
>
>Criteria:
>
>1.	Explicitly define the type of Content Encryption Key and 
>algorithm to be used in a manner that is independent of the KEK 
>algorithm type, for example by a ASN.1 structure and designated 
>algorithm ID, to avoid the N-squared proliferation of algorithm IDs 
>for various combinations of KEK and CEK types.
>
>2.	The Key Wrapping algorithm must be secure against 
>a number of recently discovered attacks or threats; in particular it 
>should be possible to securely encrypt a huge (>2^32) number of 
>CEKs in a single KEK, and vice versa to encrypt a single CEK in a 
>huge number of KEKs, without any significant possibility of information 
>leakage that might be caused by a birthday attack, i.e., two pieces of 
>matching cipher text revealing something about the plaintext. 
> 
>3.	In particular, the key wrapping format should not contain 
>any stereotyped or common information in the plaintext, whether in 
>the form of key parity bits, encryption padding bits, or other constant 
>information. Instead, some form of encryption or whitening should be 
>used to hide or mask such common information. The whitening must 
>be unique for each wrapped key. 
>
>4.	The key wrapping technique should be secure according 
>to these criteria, regardless of whether the algorithm is a symmetric 
>or an asymmetric one.  In particular, the key wrapping should be as 
>good as OAEP when used with an asymmetric key.  (Since I don't 
>consider myself to be very strong in this area, I'll leave it up to the 
>crypto-mathematicians to tell me whether I have achieved this goal.)
>
>TO ENCRYPT:
>
>1.	Generate a random Content Encryption Key of an appropriate 
>key length.  Fix up parity bits and/or any other constraints imposed by 
>the CEK algorithm.  
>
>2.	Wrap the key plus any other required parameters in a descriptive 
>ASN.1 structure which includes the CEK algorithm ID, with the resulting 
>string called CEKWRAP.  The ASN.1 structure and the various algorithm 
>IDs are TBD.
>
>3.	Add encryption padding bits (zeroes), if and as required by the 
>algorithm by computing  CEKPAD = CEKWRAP || paddingBits
>
>4.	Let LCEK = the length of CEKWRAP in bytes, a 16 bit unsigned integer
>
>5.	Compute the maximum length of CEKWRAP plus padding:
>                    LCEKPAD = LCEK + maximumAlgorithmPadding
>
>6.	Compute the length of CEKPAD in SHA-1 blocks: 
>                    LCEKSHA= floor(LCEKPAD/20) + 1
>
>7.	Generate a 160-bit random nonce, RAND 
>
>8.	Generate a sequence of LCEKSHA SHA-1 blocks: 
>                    R(0) = RAND, 
>                    R(1)=SHA-1(R(0)), ..., R(LCEKSHA)=SHA-1(R(LCEKSHA-1))
>
>9.	Generate MASK1 = R(1) || R(2) ||...||R(LCEKSHA)
>
>10.	Generate the whitened CEK plus padding by computing 
>                    CEKWH = MASK1 XOR (CEKPAD)
>
>11.	Whiten the RAND:     MRAND = SHA-1(CEKWH) XOR RAND 
>
>12.	Whiten the length:      MLCEK = LCEK XOR MRAND, using the most 
>significant 16 bits of MRAND            
>
>13.	Generate the string to be encrypted, including the length of the 
>whitened key:    MDATA = MRAND || MLCEK || CEKPAD
>
>14.	Encrypt MDATA using the chosen Key Encryption Key KEK 
>and the key encryption algorithm. If the algorithm requires an IV, use the 
>first n bits (as specified by the algorithm) of SHA-1 of the UTF-8 encoding 
>of  
>"Generalized Key Wrapping Algorithm, version 1", repeated as necessary 
>if n>160 bits (as it might be for AES).
>
>
>TO DECRYPT:
>
>1.	Decrypt MDATA using the KEK and appropriate algorithm
>
>2.	Extract MRAND (20 bytes)
>
>3.	Extract MLCEK (2 bytes)
>
>4.	Compute LCEK = MRAND XOR MLCEK (most significant 16 bits)
>
>5.	Extract CEKPAD
>
>6.	Extract CEKWH from CEKPAD by taking the first LCEK bytes
>
>7.	Compute  RAND = MRAND XOR SHA-1(CEKWH)
>
>8.	Regenerate MASK1 as before, based on the extracted RAND.
>
>9.	Extract CEKWRAP by taking the first LCEK from CEKWH XOR MASK1
>
>10.	Unwrap the CEKWRAP ASN.1 structure if and as required, 
>extracting the CEK and algorithm type, plus any other required parameters.
>
>Regards,
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>Network Security Development
>Novell, Inc.
>122 East 1700 South
>Provo, UT 84606
>[email-masked]
>1-801-861-7387

From: David Wagner <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
To: [email-masked]
Date: Mon, 8 Feb 1999 17:26:59 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I don't want to step on any toes, but frankly, I think all three of these
are much too complicated for S/MIME.  I believe in fighting complexity and
cryptographic bloat; complexity greatly introduces the potential for
subtle bugs.

S/MIME doesn't need to worry about encrypting 2^32 CEKs with the same KEK;
this threat is just off the map, as far as I can tell.  (I've never sent
2^32 emails in my life, let alone to the same party.  And prudent
cryptographic practice says you should change your KEK far more often than
this, anyway...)

I propose a much simpler algorithm.  In fact, it's so simple that it is
_provably secure_.  (Oooh...)  To me, both of these features seem to greatly
reduce the risk of surprising weaknesses.

Basic idea:  You already have some shared keying material (KEK).  So just
MAC the CEK using some shared key material, then encrypt the result using
more of the shared key material.

For the MAC, you can use SHA1-HMAC.  Secure if SHA1 satisfies some relatively
plausible cryptographic properties.  See [1].
(Or usse Triple-DES-CBC-MAC.  Provably secure if Triple-DES is, good for up
to ~ 2^30 blocks or so.  See [2].)

For encryption, you can use e.g. Triple-DES-CBC.  Provably secure if
Triple-DES is, good for up to ~ 2^32 blocks or so.  See [3].

You can also prove that the whole scheme (i.e. the composition of the MAC
and the encryption) is secure (if both components are), if you use independent
keys.  (Using the same key for the MAC and the encryption is a Bad Idea.)
In practice, true independent keys are hard to arrive at.  But you can
just derive as much keying material as you need from your KEK, and get
keys which are computationally-indistinguishable from random.

Thus, I suggest e.g. expanding the KEK with Triple-DES counter mode as far
as needed to get a MAC key + an encryption key.  This is also provably secure,
if Triple-DES is.

Result: a whole scheme which is provably secure if Triple-DES (and maybe
SHA1) are.  Seems like a potentially useful property to me...

Of course, you have to ask what exactly is "proven" by the provable security
results.  I claim that as far as I know, the proven security results will
provide everything you need for S/MIME key wrapping.
(But since you haven't specified the requirements precisely, or even at all,
there are no guarantees.  Nonetheless I think the provable security indicates
strongly that the basic approach is sound and plausible.)

Of course, I'm also coming at this as an outsider, who's only recently started
tracking the S/MIME stuff, so it's possible I've missed some requirement of
the application.  But there are enough really sharp people reading this that
if I made important oversights, I believe someone will call me on it...

Regards,
-- David

[1]  Bellare, Rogaway, Krawczyk, ``Keying hash functions for message
     authentication'', CRYPTO '96.
[2]  Bellare, Kilian, Rogaway, ``The security of cipher block chaining'',
     CRYPTO '94.
[3]  Bellare, Desai, Jokipii, Rogaway, ``A concrete security treatment
     of symmetric encryption: analysis of the DES modes of operation,''
     38th FOCS (1997).

> 
> All:
> 
> After a fair amount of open and public debate, I see three approahces to
> Triple-DES key wrapping.  In this note, I list all three.  To keep this note a
> resonable lenght, I have omitted the unwrap algorithm description.  The
> alternative algorithms are listed in my oreder of preference.  The rationale
> for my ordering is complexity.  The simplest is first, and the most complex is
> last.  If the simple wrap algorithm meets the requirements, then what value
> does the complexity add?
> 
> The S/MIME v3 specifications will include the selected Triple-DES key wrap
> algorithm as well as a variant for wrapping RC2 keys (40-128 bit keys).
> 
> Please review the algorithms.  Please do not propose improvements that are
> covered by any issued or pending patents.
> 
> Thanks for your assistance,
>   Russ
> 
> 
> = = = = = = = = = = 
> 
> 
> WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
> 
> A.1  Key Checksum
> 
> The CMS Checksum Algorithm is used to provide an content-encryption key
> integrity check value.  The algorithm is:
> 
> 1.  Compute a 20 octet SHA-1 message digest on the 
>     content-encryption key.
> 2.  Use the most significant (first) eight octets of the 
>     message digest value as the checksum value.
> 
> A.2  Triple-DES Key Wrap
> 
> 1.  Set odd parity for each of the DES key octets comprising 
>     the content-encryption key.
> 2.  Compute a 8 octet key checksum value on the content-encryption
>     key as described above.
> 3.  Concatenate the key checksum value and the content-encryption key.
>     The result is four 8 octet blocks: B1, B2, B3, and B4.
> 4.  Encrypt in CBC mode the four blocks using the key-encryption key.
>     Use an IV of all zeros.
> 5.  Reverse the order of the four ciphertext blocks.  The resulting
>     order is B4, B3, B2, and B1.
> 6.  Encrypt the four blocks a second time.  Encrypt in CBC mode 
>     using the key-encryption key.  Use an IV of all zeros.
> 
> 
> WRAP ALOGRITHM #2:  MASK AND ENCRYPT
> 
> B.1  Key Checksum
> 
> The CMS Checksum Algorithm is used to provide an content-encryption key
> integrity check value.  The algorithm is:
> 
> 1.  Compute a 20 octet SHA-1 message digest on the 
>     content-encryption key.
> 2.  Use the most significant (first) eight octets of the 
>     message digest value as the checksum value.
> 
> B.2  Triple-DES Key Wrap
> 
> 1.  Set odd parity for each of the DES key octets comprising 
>     the content-encryption key.
> 2.  Compute a 8 octet key checksum value on the content-encryption
>     key as described above.
> 3.  Generate an 8 octet random number: RAND.
> 4.  Let H1 = SHA-1 ( RAND ).
> 5.  Let H2 = SHA-1 ( H1 ).
> 6.  Let MASK equal the most significant (first) 32 octets of H1 || H2.
> 7.  Let KEYICV equal the content-encryption key concatenated with
>     the key checksum value.
> 8.  Let PLAIN = RAND || ( KEYICV XOR MASK ).
> 9.  Encrypt PLAIN in CBC mode using the key-encryption key.
>     Use an IV of all zeros.
> 
> 
> WRAP ALOGRITHM #3:  OAEP AND ENCRYPT
> 
> C.1  Key Checksum
> 
> No explicit ckecksum algoritm is needed.  The OAEP processing provides 
> the necessary integrity.
> 
> C.2  Triple-DES Key Wrap
> 
> 1.  Set odd parity for each of the DES key octets comprising 
>     the content-encryption key, called CEK.
> 2.  Let CEKPAD = 0x18 || CEK || 0x0000000000000000000000.
> 3.  Generate a 160-bit random value, called RAND.
> 4.  Let H1 = SHA-1 ( RAND || 0x01 ).
> 5.  Let H2 = SHA-1 ( RAND || 0x02 ).
> 6.  Let MASK1 equal the most significant (first) 36 octets of H1 || H2.
> 7.  Let MKEY = CEKPAD XOR MASK1.
> 8.  Let MASK2 = SHA-1 ( MKEY ).
> 9.  Let MRAND = MASK2 XOR RAND.
> 10. Let MDATA = MRAND || MKEY.
> 11. Encrypt MDATA with the key-encryption key and CBC mode.  Use an IV
>     with each octet equal to 0xA5.  The ciphertext is 56 octets long.
> 

Date: Mon, 08 Feb 1999 15:38:01 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Bob Jueneman" <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ, nice job of synthesizing various inputs into a standard format.

However, I continue to think we have two problems that have to 
be addressed. One is cryptographic, and one is architectural.

The cryptographic problem is one of not wanting to leak any
information in the case of many, many wrappings of the same CEK,
or in the case of a single KEK being used to wrap many, many CEKs;
where an observation of two matching ciphertexts might reveal information
about the plaintext if the cipher text includes any form of stereotyped of
constant information, e.g., parity bits or padding.

The architectural problem is to try to avoid the forthcoming problem of 
needing N-squared algorithm IDs in order to handle the various combinations
of key encryption keys and content encryption keys of different types that
are likely to be developed over the coming years.  

Although S/MIME may only be interested in some small number of algorithm
types today, there are lots of places where wrapped keys may be required 
in addition to S/MIME, and as a security architect I don't want to have 
to keep reinventing (and recoding) key wrapping techniques.

For this reason, I will offer my comments inline on the algorithms that you have 
proposed, and then propose a new Generalized Key Wrapping Algorithm
that attempts to take the best features of each of the three approaches you 
have described, and apply them in a more generalized way.

In addition, I've tried to explicitly state the security criteria, as I agree with 
Don Johnson.  Reasonable men can still differ, but if they don't have a common 
understanding and agreement as to the requirements, differences are almost
guaranteed.

= = = = = = = = = = 

WRAP ALGORITHM #1:  DOUBLE ENCRYPTION

A.1  Key Checksum

The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value.  The algorithm is:

1.  Compute a 20 octet SHA-1 message digest on the 
    content-encryption key.
2.  Use the most significant (first) eight octets of the 
    message digest value as the checksum value.

[RRJ]  I'm really not convinced of the necessity for a key checksum, although
I certainly have not followed all of the previous discussion.  If someone were 
trying to attack the key distribution mechanism, then the key checksum
could act as an oracle. I would _much_ prefer to checksum the entire result,
i.e., the final encrypted  key, than to checksum the CEK itself.  Is there some 
strong justification for this that I've missed, such as the French stop-code
requirement?

A.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key.
2.  Compute a 8 octet key checksum value on the content-encryption
    key as described above.
3.  Concatenate the key checksum value and the content-encryption key.
    The result is four 8 octet blocks: B1, B2, B3, and B4.
4.  Encrypt in CBC mode the four blocks using the key-encryption key.
    Use an IV of all zeros.
5.  Reverse the order of the four ciphertext blocks.  The resulting
    order is B4, B3, B2, and B1.

[RRJ] Rather than merely interchange the order of the four blocks, I believe 
that the entire string should be reversed, byte for byte. (I'd really like
to do it bit by bit, but the code would be a little awkward.) Preserving the
original block boundaries might possibly allow some clever attacks. I also
don't see the need for the final reversal.  

6.  Encrypt the four blocks a second time.  Encrypt in CBC mode 
    using the key-encryption key.  Use an IV of all zeros.

[RRJ]  I would prefer to use something other than 0 for the IV.
Ideally, the IV should be variable for each KEK, in order to make
a chosen plaintext attack that much more difficult. If a varying IV is
too difficult from a protocol standpoint, then at least avoid any kind of 
repeating structure -- use pi, or the square root of 2, or something
random.  And use two different IVs for the different steps.
Tom Berson is absolutely right -- avoid structure and 
symmetry at all cost!

[RRJ]  But my primary objection to this approach is the expense incurred by the 
second encryption pass. Even though a triple-DES operation may be quite
fast compared to say an RSA encryption, cycles are cycles, and
deliberately causing additional key management overhead that could be
avoided is unacceptable.

WRAP ALGORITHM #2:  MASK AND ENCRYPT

B.1  Key Checksum

The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value.  The algorithm is:

1.  Compute a 20 octet SHA-1 message digest on the 
    content-encryption key.
2.  Use the most significant (first) eight octets of the 
    message digest value as the checksum value.

B.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key.
2.  Compute a 8 octet key checksum value on the content-encryption
    key as described above.
3.  Generate an 8 octet random number: RAND.
4.  Let H1 = SHA-1 ( RAND ).
5.  Let H2 = SHA-1 ( H1 ).
6.  Let MASK equal the most significant (first) 32 octets of H1 || H2.

[RRJ] H2 is in some sense "more random" than H1, since it includes 
the mixing effect of the previous SHA-1.  If RAND were less than perfectly
random, i.e., subject to some kind of bias, H1 might remove most, but perhaps
not all of the bias, but if SHA-1 is any good at all, H2 should be much
less likely to leak information. For that reason, and since CBC introduces 
error propagation in the forward direction, MASK should equal the most 
significant (first) 32 octets of H2 || H1.

7.  Let KEYICV equal the content-encryption key concatenated with
    the key checksum value.

[RRJ] For the reason given above, forward error propagation, the KEYICV should
be formed by taking the key checksum concatenated with (followed by)
the CEK.  But I would greatly prefer not to have a key checksum at all, 
in which case MASK would only be 24 octets long, assuming a "naked" 
triple-DES CEK.

8.  Let PLAIN = RAND || ( KEYICV XOR MASK ).

[RRJ] The disadvantage of this approach, as compared to approach 3
(OAEP), is that the RAND is not whitened. Therefore, if there is any weakness
in RAND, it may be possible to derive some information from any block that has a
matching ciphertext.

9.  Encrypt PLAIN in CBC mode using the key-encryption key.
    Use an IV of all zeros.

WRAP ALGORITHM #3:  OAEP AND ENCRYPT

C.1  Key Checksum

No explicit checksum algorism is needed.  The OAEP processing provides 
the necessary integrity.

C.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key, called CEK.
2.  Let CEKPAD = 0x18 || CEK || 0x0000000000000000000000.
3.  Generate a 160-bit random value, called RAND.
4.  Let H1 = SHA-1 ( RAND || 0x01 ).
5.  Let H2 = SHA-1 ( RAND || 0x02 ).
6.  Let MASK1 equal the most significant (first) 36 octets of H1 || H2.

[RRJ]  I would prefer that a stronger function than this be used.
As it stands, the input to the two SHA-1 routines differ by only
two bits.  Use the approach of scheme 2 as modified above, i.e.,
Let H1 = SHA-1 ( RAND ),  H2 = SHA-1 ( H1 ) , 
MASK1 equal the most significant (first) 36 octets of H2 || H1.

7.  Let MKEY = CEKPAD XOR MASK1.
8.  Let MASK2 = SHA-1 ( MKEY ).
9.  Let MRAND = MASK2 XOR RAND.
10. Let MDATA = MRAND || MKEY.
11. Encrypt MDATA with the key-encryption key and CBC mode.  Use an IV
    with each octet equal to 0xA5.  The ciphertext is 56 octets long.

[RRJ]  Again, there is absolutely no reason to deliberately introduce
structure and symmetry in the IV.  If possible, use a real IV that varies 
for each KEK, in order to make a chosen plaintext attack that much 
more difficult.  At a minimum, use a pseudo-random constant with no 
apparent structure.

[RRJ]  If these problems were fixed, I believe that Approach 3 would be my 
favorite of those above, because it seems to be the most secure 
without introducing an unnecessary second encryption step.

However, I believe we can do better yet. Here is my recommended approach, 
one that tries to take advantage of all of the tweaks included above.

======================

GENERALIZED KEY WRAPPING ALGORITHM (Version 1)

Criteria:

1.	Explicitly define the type of Content Encryption Key and 
algorithm to be used in a manner that is independent of the KEK 
algorithm type, for example by a ASN.1 structure and designated 
algorithm ID, to avoid the N-squared proliferation of algorithm IDs 
for various combinations of KEK and CEK types.

2.	The Key Wrapping algorithm must be secure against 
a number of recently discovered attacks or threats; in particular it 
should be possible to securely encrypt a huge (>2^32) number of 
CEKs in a single KEK, and vice versa to encrypt a single CEK in a 
huge number of KEKs, without any significant possibility of information 
leakage that might be caused by a birthday attack, i.e., two pieces of 
matching cipher text revealing something about the plaintext. 
 
3.	In particular, the key wrapping format should not contain 
any stereotyped or common information in the plaintext, whether in 
the form of key parity bits, encryption padding bits, or other constant 
information. Instead, some form of encryption or whitening should be 
used to hide or mask such common information. The whitening must 
be unique for each wrapped key. 

4.	The key wrapping technique should be secure according 
to these criteria, regardless of whether the algorithm is a symmetric 
or an asymmetric one.  In particular, the key wrapping should be as 
good as OAEP when used with an asymmetric key.  (Since I don't 
consider myself to be very strong in this area, I'll leave it up to the 
crypto-mathematicians to tell me whether I have achieved this goal.)

TO ENCRYPT:

1.	Generate a random Content Encryption Key of an appropriate 
key length.  Fix up parity bits and/or any other constraints imposed by 
the CEK algorithm.  

2.	Wrap the key plus any other required parameters in a descriptive 
ASN.1 structure which includes the CEK algorithm ID, with the resulting 
string called CEKWRAP.  The ASN.1 structure and the various algorithm 
IDs are TBD.

3.	Add encryption padding bits (zeroes), if and as required by the 
algorithm by computing  CEKPAD = CEKWRAP || paddingBits

4.	Let LCEK = the length of CEKWRAP in bytes, a 16 bit unsigned integer

5.	Compute the maximum length of CEKWRAP plus padding:
                    LCEKPAD = LCEK + maximumAlgorithmPadding

6.	Compute the length of CEKPAD in SHA-1 blocks: 
                    LCEKSHA= floor(LCEKPAD/20) + 1

7.	Generate a 160-bit random nonce, RAND 

8.	Generate a sequence of LCEKSHA SHA-1 blocks: 
                    R(0) = RAND, 
                    R(1)=SHA-1(R(0)), ..., R(LCEKSHA)=SHA-1(R(LCEKSHA-1))

9.	Generate MASK1 = R(1) || R(2) ||...||R(LCEKSHA)

10.	Generate the whitened CEK plus padding by computing 
                    CEKWH = MASK1 XOR (CEKPAD)

11.	Whiten the RAND:     MRAND = SHA-1(CEKWH) XOR RAND 

12.	Whiten the length:      MLCEK = LCEK XOR MRAND, using the most 
significant 16 bits of MRAND            

13.	Generate the string to be encrypted, including the length of the 
whitened key:    MDATA = MRAND || MLCEK || CEKPAD

14.	Encrypt MDATA using the chosen Key Encryption Key KEK 
and the key encryption algorithm. If the algorithm requires an IV, use the 
first n bits (as specified by the algorithm) of SHA-1 of the UTF-8 encoding of  
"Generalized Key Wrapping Algorithm, version 1", repeated as necessary 
if n>160 bits (as it might be for AES).

TO DECRYPT:

1.	Decrypt MDATA using the KEK and appropriate algorithm

2.	Extract MRAND (20 bytes)

3.	Extract MLCEK (2 bytes)

4.	Compute LCEK = MRAND XOR MLCEK (most significant 16 bits)

5.	Extract CEKPAD

6.	Extract CEKWH from CEKPAD by taking the first LCEK bytes

7.	Compute  RAND = MRAND XOR SHA-1(CEKWH)

8.	Regenerate MASK1 as before, based on the extracted RAND.

9.	Extract CEKWRAP by taking the first LCEK from CEKWH XOR MASK1

10.	Unwrap the CEKWRAP ASN.1 structure if and as required, 
extracting the CEK and algorithm type, plus any other required parameters.

Regards,

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

Date: Mon, 08 Feb 1999 16:28:05 -0500
To: William Whyte <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Counter format in x942-05
Cc: "'EKR'" <[email-masked]>, "'IETF SMIME list'" <[email-masked]>
Sender: [email-masked]

Yes, your document is out of date.  The counter is OCTET STRING (SIZE
4..4).  I confiremed this at the X9F1 meeting in January.  If you notice,
the text and the ASN.1 are not in sync in the version you have.

Russ

At 03:07 PM 2/8/99 +0000, William Whyte wrote:
>In my draft of X9.42 (October 2nd, 1998), the counter is an INTEGER, not an 
>OCTET STRING. Is my draft out of date?
>
>Cheers,
>
>William

Date: Mon, 08 Feb 1999 14:16:14 -0500
To: "Don Johnson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Don:

I thought about writing a list of criteria, but I did not want to start a
debate about the criteria.  Rather, I want to focus on the algorithms.  For
the most part, the folks on this list undertsand the requirements
associated with key wrapping.

Russ

At 10:10 AM 2/8/99 -0500, Don Johnson wrote:
>Russ,
>
>To be fair, you should explicitly state the security attributes required by
>the process, that is, if this attribute is not achieved, it should be
>considered an attack and if a attribute is not mentioned, it is not
>considered an attack if it is not achieved.  For example, confidentiality
>so that no bit of the key can be guessed with substantially better than 50%
>probability, detection of alteration with 1/x probability, plaintext
>awareness, etc.
>
>Don Johnson
>
>
>
>
>
>Russ Housley <[email-masked]> on 02/07/99 04:07:18 PM
>
>To:   [email-masked]
>cc:   [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked], [email-masked],
>      [email-masked], [email-masked],
>      [email-masked] (bcc: Don Johnson/Certicom)
>Subject:  Re: A New Triple-DES Key Wrap Algorithm
>
>
>
>
>All:
>
>After a fair amount of open and public debate, I see three approahces to
>Triple-DES key wrapping.  In this note, I list all three.  To keep this
>note a
>resonable lenght, I have omitted the unwrap algorithm description.  The
>alternative algorithms are listed in my oreder of preference.  The
>rationale
>for my ordering is complexity.  The simplest is first, and the most complex
>is
>last.  If the simple wrap algorithm meets the requirements, then what value
>does the complexity add?
>
>The S/MIME v3 specifications will include the selected Triple-DES key wrap
>algorithm as well as a variant for wrapping RC2 keys (40-128 bit keys).
>
>Please review the algorithms.  Please do not propose improvements that are
>covered by any issued or pending patents.
>
>Thanks for your assistance,
>  Russ
>
>
>= = = = = = = = = =
>
>
>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>
>A.1  Key Checksum
>
>The CMS Checksum Algorithm is used to provide an content-encryption key
>integrity check value.  The algorithm is:
>
>1.  Compute a 20 octet SHA-1 message digest on the
>    content-encryption key.
>2.  Use the most significant (first) eight octets of the
>    message digest value as the checksum value.
>
>A.2  Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising
>    the content-encryption key.
>2.  Compute a 8 octet key checksum value on the content-encryption
>    key as described above.
>3.  Concatenate the key checksum value and the content-encryption key.
>    The result is four 8 octet blocks: B1, B2, B3, and B4.
>4.  Encrypt in CBC mode the four blocks using the key-encryption key.
>    Use an IV of all zeros.
>5.  Reverse the order of the four ciphertext blocks.  The resulting
>    order is B4, B3, B2, and B1.
>6.  Encrypt the four blocks a second time.  Encrypt in CBC mode
>    using the key-encryption key.  Use an IV of all zeros.
>
>
>WRAP ALOGRITHM #2:  MASK AND ENCRYPT
>
>B.1  Key Checksum
>
>The CMS Checksum Algorithm is used to provide an content-encryption key
>integrity check value.  The algorithm is:
>
>1.  Compute a 20 octet SHA-1 message digest on the
>    content-encryption key.
>2.  Use the most significant (first) eight octets of the
>    message digest value as the checksum value.
>
>B.2  Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising
>    the content-encryption key.
>2.  Compute a 8 octet key checksum value on the content-encryption
>    key as described above.
>3.  Generate an 8 octet random number: RAND.
>4.  Let H1 = SHA-1 ( RAND ).
>5.  Let H2 = SHA-1 ( H1 ).
>6.  Let MASK equal the most significant (first) 32 octets of H1 || H2.
>7.  Let KEYICV equal the content-encryption key concatenated with
>    the key checksum value.
>8.  Let PLAIN = RAND || ( KEYICV XOR MASK ).
>9.  Encrypt PLAIN in CBC mode using the key-encryption key.
>    Use an IV of all zeros.
>
>
>WRAP ALOGRITHM #3:  OAEP AND ENCRYPT
>
>C.1  Key Checksum
>
>No explicit ckecksum algoritm is needed.  The OAEP processing provides
>the necessary integrity.
>
>C.2  Triple-DES Key Wrap
>
>1.  Set odd parity for each of the DES key octets comprising
>    the content-encryption key, called CEK.
>2.  Let CEKPAD = 0x18 || CEK || 0x0000000000000000000000.
>3.  Generate a 160-bit random value, called RAND.
>4.  Let H1 = SHA-1 ( RAND || 0x01 ).
>5.  Let H2 = SHA-1 ( RAND || 0x02 ).
>6.  Let MASK1 equal the most significant (first) 36 octets of H1 || H2.
>7.  Let MKEY = CEKPAD XOR MASK1.
>8.  Let MASK2 = SHA-1 ( MKEY ).
>9.  Let MRAND = MASK2 XOR RAND.
>10. Let MDATA = MRAND || MKEY.
>11. Encrypt MDATA with the key-encryption key and CBC mode.  Use an IV
>    with each octet equal to 0xA5.  The ciphertext is 56 octets long.
>
>
>
>
>

From: "Don Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 8 Feb 1999 10:10:07 -0500
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ,

To be fair, you should explicitly state the security attributes required by
the process, that is, if this attribute is not achieved, it should be
considered an attack and if a attribute is not mentioned, it is not
considered an attack if it is not achieved.  For example, confidentiality
so that no bit of the key can be guessed with substantially better than 50%
probability, detection of alteration with 1/x probability, plaintext
awareness, etc.

Don Johnson

Russ Housley <[email-masked]> on 02/07/99 04:07:18 PM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked] (bcc: Don Johnson/Certicom)
Subject:  Re: A New Triple-DES Key Wrap Algorithm

All:

After a fair amount of open and public debate, I see three approahces to
Triple-DES key wrapping.  In this note, I list all three.  To keep this
note a
resonable lenght, I have omitted the unwrap algorithm description.  The
alternative algorithms are listed in my oreder of preference.  The
rationale
for my ordering is complexity.  The simplest is first, and the most complex
is
last.  If the simple wrap algorithm meets the requirements, then what value
does the complexity add?

The S/MIME v3 specifications will include the selected Triple-DES key wrap
algorithm as well as a variant for wrapping RC2 keys (40-128 bit keys).

Please review the algorithms.  Please do not propose improvements that are
covered by any issued or pending patents.

Thanks for your assistance,
  Russ

= = = = = = = = = =

WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION

A.1  Key Checksum

The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value.  The algorithm is:

1.  Compute a 20 octet SHA-1 message digest on the
    content-encryption key.
2.  Use the most significant (first) eight octets of the
    message digest value as the checksum value.

A.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising
    the content-encryption key.
2.  Compute a 8 octet key checksum value on the content-encryption
    key as described above.
3.  Concatenate the key checksum value and the content-encryption key.
    The result is four 8 octet blocks: B1, B2, B3, and B4.
4.  Encrypt in CBC mode the four blocks using the key-encryption key.
    Use an IV of all zeros.
5.  Reverse the order of the four ciphertext blocks.  The resulting
    order is B4, B3, B2, and B1.
6.  Encrypt the four blocks a second time.  Encrypt in CBC mode
    using the key-encryption key.  Use an IV of all zeros.

WRAP ALOGRITHM #2:  MASK AND ENCRYPT

B.1  Key Checksum

The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value.  The algorithm is:

1.  Compute a 20 octet SHA-1 message digest on the
    content-encryption key.
2.  Use the most significant (first) eight octets of the
    message digest value as the checksum value.

B.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising
    the content-encryption key.
2.  Compute a 8 octet key checksum value on the content-encryption
    key as described above.
3.  Generate an 8 octet random number: RAND.
4.  Let H1 = SHA-1 ( RAND ).
5.  Let H2 = SHA-1 ( H1 ).
6.  Let MASK equal the most significant (first) 32 octets of H1 || H2.
7.  Let KEYICV equal the content-encryption key concatenated with
    the key checksum value.
8.  Let PLAIN = RAND || ( KEYICV XOR MASK ).
9.  Encrypt PLAIN in CBC mode using the key-encryption key.
    Use an IV of all zeros.

WRAP ALOGRITHM #3:  OAEP AND ENCRYPT

C.1  Key Checksum

No explicit ckecksum algoritm is needed.  The OAEP processing provides
the necessary integrity.

C.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising
    the content-encryption key, called CEK.
2.  Let CEKPAD = 0x18 || CEK || 0x0000000000000000000000.
3.  Generate a 160-bit random value, called RAND.
4.  Let H1 = SHA-1 ( RAND || 0x01 ).
5.  Let H2 = SHA-1 ( RAND || 0x02 ).
6.  Let MASK1 equal the most significant (first) 36 octets of H1 || H2.
7.  Let MKEY = CEKPAD XOR MASK1.
8.  Let MASK2 = SHA-1 ( MKEY ).
9.  Let MRAND = MASK2 XOR RAND.
10. Let MDATA = MRAND || MKEY.
11. Encrypt MDATA with the key-encryption key and CBC mode.  Use an IV
    with each octet equal to 0xA5.  The ciphertext is 56 octets long.

From: William Whyte <[email-masked]>
To: "'EKR'" <[email-masked]>
Cc: "'IETF SMIME list'" <[email-masked]>
Subject: Counter format in x942-05
Date: Mon, 8 Feb 1999 15:07:26 -0000
Organization: Baltimore Technologies
Sender: [email-masked]

In my draft of X9.42 (October 2nd, 1998), the counter is an INTEGER, not an OCTET STRING. Is my draft out of date?

Cheers,

William

Date: Sun, 07 Feb 1999 16:07:18 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

All:

After a fair amount of open and public debate, I see three approahces to
Triple-DES key wrapping.  In this note, I list all three.  To keep this note a
resonable lenght, I have omitted the unwrap algorithm description.  The
alternative algorithms are listed in my oreder of preference.  The rationale
for my ordering is complexity.  The simplest is first, and the most complex is
last.  If the simple wrap algorithm meets the requirements, then what value
does the complexity add?

The S/MIME v3 specifications will include the selected Triple-DES key wrap
algorithm as well as a variant for wrapping RC2 keys (40-128 bit keys).

Please review the algorithms.  Please do not propose improvements that are
covered by any issued or pending patents.

Thanks for your assistance,
  Russ

= = = = = = = = = = 

WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION

A.1  Key Checksum

The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value.  The algorithm is:

1.  Compute a 20 octet SHA-1 message digest on the 
    content-encryption key.
2.  Use the most significant (first) eight octets of the 
    message digest value as the checksum value.

A.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key.
2.  Compute a 8 octet key checksum value on the content-encryption
    key as described above.
3.  Concatenate the key checksum value and the content-encryption key.
    The result is four 8 octet blocks: B1, B2, B3, and B4.
4.  Encrypt in CBC mode the four blocks using the key-encryption key.
    Use an IV of all zeros.
5.  Reverse the order of the four ciphertext blocks.  The resulting
    order is B4, B3, B2, and B1.
6.  Encrypt the four blocks a second time.  Encrypt in CBC mode 
    using the key-encryption key.  Use an IV of all zeros.

WRAP ALOGRITHM #2:  MASK AND ENCRYPT

B.1  Key Checksum

The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value.  The algorithm is:

1.  Compute a 20 octet SHA-1 message digest on the 
    content-encryption key.
2.  Use the most significant (first) eight octets of the 
    message digest value as the checksum value.

B.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key.
2.  Compute a 8 octet key checksum value on the content-encryption
    key as described above.
3.  Generate an 8 octet random number: RAND.
4.  Let H1 = SHA-1 ( RAND ).
5.  Let H2 = SHA-1 ( H1 ).
6.  Let MASK equal the most significant (first) 32 octets of H1 || H2.
7.  Let KEYICV equal the content-encryption key concatenated with
    the key checksum value.
8.  Let PLAIN = RAND || ( KEYICV XOR MASK ).
9.  Encrypt PLAIN in CBC mode using the key-encryption key.
    Use an IV of all zeros.

WRAP ALOGRITHM #3:  OAEP AND ENCRYPT

C.1  Key Checksum

No explicit ckecksum algoritm is needed.  The OAEP processing provides 
the necessary integrity.

C.2  Triple-DES Key Wrap

1.  Set odd parity for each of the DES key octets comprising 
    the content-encryption key, called CEK.
2.  Let CEKPAD = 0x18 || CEK || 0x0000000000000000000000.
3.  Generate a 160-bit random value, called RAND.
4.  Let H1 = SHA-1 ( RAND || 0x01 ).
5.  Let H2 = SHA-1 ( RAND || 0x02 ).
6.  Let MASK1 equal the most significant (first) 36 octets of H1 || H2.
7.  Let MKEY = CEKPAD XOR MASK1.
8.  Let MASK2 = SHA-1 ( MKEY ).
9.  Let MRAND = MASK2 XOR RAND.
10. Let MDATA = MRAND || MKEY.
11. Encrypt MDATA with the key-encryption key and CBC mode.  Use an IV
    with each octet equal to 0xA5.  The ciphertext is 56 octets long.

Date: Sat, 6 Feb 1999 09:46:58 +0800 (CST)
To: [email-masked]
From: Richard Jui-Ching Shyur <[email-masked]>
Subject: Re: ADV: Is This You ?
Cc: [email-masked]
Sender: [email-masked]

So [email-masked] is also suffering from spamming...

At 03:07 PM 1999/2/5, you wrote:
>
>Are You Paying More Than You Have To...
>For Long Distance & Phone Services ???
>
>Most People Are Over-Paying - And Getting Less...
>
>Are You Getting A Deal Like This From YOUR Carrier ?
>
>*8.9 Cents/Min (24 Hours/Day) (Lower Rates Below)
>*Receive 30 Minutes Of F-R-E-E Calling For Signing Up 
>*6 Second Billing (Saves 20% More)
>*NO Sign-Up Fees
>*NO Monthly Billing Fees
>*NO Minimum Usage
>*No Gimmicks
>
>Toll-Free Numbers Are Also Only 8.9 Cents/Min
>With 6 Second Billing & No Set-Up/Transfer Fee
>
>Callings Cards - Just 14.9 Cents/Min 
>6 Second Billing - NO " Bong " Charges 
>
>P-L-U-S 
>
>Get 30 Minutes Of FREE Calling For EACH Person That You
>Refer Who Signs Up For Service - Refer 3 People Who Sign
>Up & YOUR Rate Lowers To 7.9 CENTS/MIN - PERMANENTLY ! 
>
>A-N-D
>
>EVERYONE That You Refer, Who Signs Up For Service, ALSO 
>Gets 30 Minutes Of FREE Calling !
>
>Get Your Final Cost Per Minute Down To 5 Cents/Min,
>3 Cents/Min, Even Down To ZERO - With Our Referral
>Program - It's Totally FREE To You & The People That
>You Refer !
>
>When We Get A Lower Rate - YOUR Rate Goes DOWN
>A-U-T-O-M-A-T-I-C-A-L-L-Y. Unlike Other Carriers, Our
>Prices Have NEVER Gone Up - Only Down - And They
>Continue To Do So !
>
>Call Us Today For More Info - Or To Sign Up !
>
>1-888-333-4943
>
>(TOLL-FREE)
>
>Monday-Friday
>10 AM - 10 PM
>Eastern
>
>
>
>P. S. 
>
>We Receive Hundreds Of Calls Per Day. If Lines 
>Are Busy - Keep Trying. This Is An Information
>And Sign-Up Line.If You Sign-Up For The Service,
>You Will Have The Direct Toll-Free Numbers For 
>Our Customer Service & Billing Departments.
>
+-----------------------------------------------+
| Chunghwa Telecom, Tele Labs	  886-3-4244110 |
| 			      fax:886-3-4244167 |
|            Dr. Richard Jui-Ching Shyur ®}·çë |
+-----------------------------------------------+

Date: Fri, 5 Feb 1999 17:53:15 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Last Call Comment on ESS - Signing Certificate Attribute
Sender: [email-masked]

All,

I agree with all of Francois Rousseau's comments to Jim's proposal to expand
the use of the signingCertificate attribute.

=========================================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================

From: [email-masked]
To: [email-masked]
Subject: ADV: Is This You ?
Date: Fri, 5 Feb 1999 15:07:11
Sender: [email-masked]

Are You Paying More Than You Have To...
For Long Distance & Phone Services ???

Most People Are Over-Paying - And Getting Less...

Are You Getting A Deal Like This From YOUR Carrier ?

*8.9 Cents/Min (24 Hours/Day) (Lower Rates Below)
*Receive 30 Minutes Of F-R-E-E Calling For Signing Up 
*6 Second Billing (Saves 20% More)
*NO Sign-Up Fees
*NO Monthly Billing Fees
*NO Minimum Usage
*No Gimmicks

Toll-Free Numbers Are Also Only 8.9 Cents/Min
With 6 Second Billing & No Set-Up/Transfer Fee

Callings Cards - Just 14.9 Cents/Min 
6 Second Billing - NO " Bong " Charges 

P-L-U-S 

Get 30 Minutes Of FREE Calling For EACH Person That You
Refer Who Signs Up For Service - Refer 3 People Who Sign
Up & YOUR Rate Lowers To 7.9 CENTS/MIN - PERMANENTLY ! 

A-N-D

EVERYONE That You Refer, Who Signs Up For Service, ALSO 
Gets 30 Minutes Of FREE Calling !

Get Your Final Cost Per Minute Down To 5 Cents/Min,
3 Cents/Min, Even Down To ZERO - With Our Referral
Program - It's Totally FREE To You & The People That
You Refer !

When We Get A Lower Rate - YOUR Rate Goes DOWN
A-U-T-O-M-A-T-I-C-A-L-L-Y. Unlike Other Carriers, Our
Prices Have NEVER Gone Up - Only Down - And They
Continue To Do So !

Call Us Today For More Info - Or To Sign Up !

1-888-333-4943

(TOLL-FREE)

Monday-Friday
10 AM - 10 PM
Eastern

P. S. 

We Receive Hundreds Of Calls Per Day. If Lines 
Are Busy - Keep Trying. This Is An Information
And Sign-Up Line.If You Sign-Up For The Service,
You Will Have The Direct Toll-Free Numbers For 
Our Customer Service & Billing Departments.

Date: Fri, 05 Feb 1999 11:18:06 -0500
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: Last Call Comment on ESS - Signing Certificate Attribute
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Jim,

I agree with you that authorization/access control information can also be
distributed through the "subject directory attributes" extension of a
public key certificate (e.g. US DoD Partition Rule Based Access Control
(PRBAC) scheme) instead of or in addition to attribute certificates (e.g.
US DoD Local Rule Based Access Control (LRBAC) scheme) as it has also been
recognized in the latest Proposed Draft Amendment (PDAM) to X.509(97).

This authorization/access control information can be included with the
signature verification public key certificate, the encryption public key
certificate or both public key certificates, and there was currently no
mean to bind it to the encryption public key certificate.

However in addition to changing only paragraph 4 of Section 5.4 as you have
proposed, I would suggest that the following paragraphs may also have to be
changed:

a.  May be the new wording about signing certificates (Section 5) in the
introduction in Section 1 will have to be changed.

b.  Section 5, paragraph 3,

Attribute certificates and other public key certificates can be used as
part of a signature verification process. There is no way in CMS to include
the list of other certificates to be used in the verification process. The
signer needs to have the ability to restrict the set of certificates used
in the signature verification process. This information needs to be encoded
in a manner that is covered by the signature on the SignedData object. The
methods in this section allows for the set of certificates to be listed as
part of the signing certificate attribute.

c.  Section 5.3,

Some applications require that additional information be used as part of
the signature validation process. In particular, attribute certificates,
other public key certificates and policy identifiers provide additional
information about the abilities and intent of the signer. The signing
certificate attribute described in Section 5.4 provides the ability to bind
this context information as part of the signature.

d.  Section 5.3.1,

5.3.1 Other Certificates

Some applications require that attribute certificates and/or other public
key certificates be validated. This validation requires that the
application be able to find the correct certificates to perform the
verification process; however there is no list of other certificates to
used in a SignerInfo object. The sender has the ability to include a set of
attribute certificates and public key certificates in a SignedData object.
The receiver has the ability to retrieve attribute certificates and public
key certificates from a directory service. There are some circumstances
where the signer may wish to limit the set of certificates that may be used
in verifying a signature. It is useful to be able to list the set of
certificates the signer wants the recipient to use in validating the
signature.

e.  Section 5.4, paragraph 1,

The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set of
certificates to be used in verifying a signature.

f.  Section 5.4.1, paragraph 2,

Attribute certificates and additional public key certificates do not have
an issuer/serial number pair represented anywhere in a SignerInfo object.
When an attribute certificate or an additional public key certificate is
not included in the SignedData object, it becomes much more difficult to
get the correct set of certificates based only on a hash of the
certificate. For this reason, attribute certificates or additional public
key certificates are identified by the IssuerSerial object.

Any Comments?

Francois Rousseau
AEPOS Technologies

>In reviewing some requirements that are coming from external companies on
>our product requirements and I found the following problem.
>
>It turns out that not everybody is up to the point of using attribute
>certificates for assigning authorizations.  This information is being
>carried in normal authentication certificates and ususally in an encryption
>certificate rather than the signing certificate.  This means that we need to
>allow more than attribute certificates in the last portion of the list.
>
>
>
>Replace Section 5.4 paragraph 4 with the following:
>
>If more than one certificate is present in the sequence of ESSCertIDs, the
>certificates after the first one limit the set of authorization certificates
>that are used during signature validation. Authorization certificates can be
>both attribute certificates and normal certificates. The issuerSerial SHOULD
>be
>present in these certificates, unless the client who is validating the
>signature is expected to have easy access to all the certificates required
>for validation. If only the signing certificate is present in the sequence.
>there are no restrictions on the set of authorization certificates used in
>validating the signature.
>
>jim
>
>

From: [email-masked]
Date: Fri, 5 Feb 1999 15:01:42 +0000
Subject: RE: Re: A New Triple-DES Key Wrap Algorithm
To: [email-masked]
Sender: [email-masked]

I don't think we should be overly concerned about performance or code size. 

We are primarily talking about user orientated clients where another x hundred 
milliseconds is not going to be a significant problem and Microsoft seem to be 
doing their best to ensure that we have oodles of RAM available if needed.

When one considers the ever increasing speed of processors, what is not 
lightning fast now probably will be tomorrow and, perhaps more importantly, the 
processors used to attack the messages encrypted today definitely will be much, 
much faster in the future.

Our primary goal should be security, with ease of implementation next.

Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England

Tel +44-171-500-6473
Fax +44-171-500-8880

----Original Message-----
From: owner-ietf-smime(a)imc.org 
Sent: Saturday, February 06, 1999 7:18 AM
To: BJUENEMAN(a)novell.com; ietf-smime(a)imc.org
Cc: pgut001(a)cs.aucKland.ac.nz
Subject: Re: A New Triple-DES Key Wrap Algorithm

[email-masked], [email-masked], [email-masked], 
[email-masked]

>The only [small] problem I have with your approach is performance, as double 
>encryption with triple-DES is relatively expensive, especially if you don't 
>save and reuse the state after the three key expansions step in DES.  In 
>addition, I would like to have a key wrapper format that is completely 
>independent of the KEK algorithm, soi that I can use the same wrapper whether 
>I use DES, RSA, elliptic curves, etc. And I don't think you want to propose 
>doing double encryption with an asymmetric cipher!
 
I chose it because two passes of whatever cipher was being used seemed the 
simplest way to do it.  There are many alternative to this, my immediate 
reaction when I saw the original analysis was to use the cipher to generate a 
pseudorandom stream, hash 128-bit chunks of it with SHA-1, and then XOR the 
20-byte blocks into the data to be encrypted, but it's a bit of an ad hoc 
approach and requires many applications of SHA-1 which are probably less 
efficient than the block cipher.  In any case I doubt that a handful of extra 
en/decryption operations for the two-pass crypt are going to add much 
overhead.  This is the same scheme suggested by Don Johnson, I wasn't sure 
initially whether we were talking about the same thing.                    
 
Historical note: I first used something like this for a sector-level 
encrypting disk device driver where there wasn't any room for storing the IV, 
so the encryption made two passes, the first to generate the IV and the second 
to perform the encryption.  The first pass used:
 
    P[ i ] ^= P[ i-K1 ] ^ P[ i-K2 ]
 
(K1 and K2 are appropriate constants), the second pass used the output as the 
IV.  This is a nice lightweight function (it's extremely efficient on a RISC 
CPU), the design was by Colin Plumb and was inspired by the (then brand-new) 
SHA.  In the KEK case you don't need this since the data is so short that two 
applications of the block cipher will carry virtually no overhead.
 
Peter.

 << File: UnXhrds.txt >> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: A New Triple-DES Key Wrap Algorithm
Reply-To: [email-masked]
Date: Sat, 6 Feb 1999 02:18:19 (NZDT)
Sender: [email-masked]

[email-masked], [email-masked], [email-masked], [email-masked]

>The only [small] problem I have with your approach is performance, as double 
>encryption with triple-DES is relatively expensive, especially if you don't 
>save and reuse the state after the three key expansions step in DES.  In 
>addition, I would like to have a key wrapper format that is completely 
>independent of the KEK algorithm, soi that I can use the same wrapper whether 
>I use DES, RSA, elliptic curves, etc. And I don't think you want to propose 
>doing double encryption with an asymmetric cipher!
 
I chose it because two passes of whatever cipher was being used seemed the 
simplest way to do it.  There are many alternative to this, my immediate 
reaction when I saw the original analysis was to use the cipher to generate a 
pseudorandom stream, hash 128-bit chunks of it with SHA-1, and then XOR the 
20-byte blocks into the data to be encrypted, but it's a bit of an ad hoc 
approach and requires many applications of SHA-1 which are probably less 
efficient than the block cipher.  In any case I doubt that a handful of extra 
en/decryption operations for the two-pass crypt are going to add much 
overhead.  This is the same scheme suggested by Don Johnson, I wasn't sure 
initially whether we were talking about the same thing.                    
 
Historical note: I first used something like this for a sector-level 
encrypting disk device driver where there wasn't any room for storing the IV, 
so the encryption made two passes, the first to generate the IV and the second 
to perform the encryption.  The first pass used:
 
    P[ i ] ^= P[ i-K1 ] ^ P[ i-K2 ]
 
(K1 and K2 are appropriate constants), the second pass used the output as the 
IV.  This is a nice lightweight function (it's extremely efficient on a RISC 
CPU), the design was by Colin Plumb and was inspired by the (then brand-new) 
SHA.  In the KEK case you don't need this since the data is so short that two 
applications of the block cipher will carry virtually no overhead.
 
Peter.

Date: Thu, 04 Feb 1999 17:12:23 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Fair enough, Russ.

The only problem is that I have never known a standard that didn't 
end up being picked up and used by another group, many times inappropriately,
because they didn't understand the context and limitations of the original effort.

Any comments on my proposed solution?

bob

>>> Russ Housley <[email-masked]> 02/04/99 02:18PM >>>
Bob:

I do not mind if a group goes off and solves the most general problem, but
that is not the problem that I have.

In the S/MIME v3 environment and other environments that use the
Cryptographic Message Syntax (CMS), the KEK and CEK will always be
symmetric keys.  If we could come to closure on one symmetric key wrapping
another symmetric key, it would be very helpful to the S/MIME v3 effort.
In fact, wrapping one 3DES key in another 3DES key is the highest priority,
and wrapping one RC2 key in another RC2 128-bit key is the next highest
priority.

Russ

At 12:57 PM 2/4/99 -0700, Bob Jueneman wrote:
>Peter,
>
>The only [small] problem I have with your approach is performance,
>as double encryption with triple-DES is relatively expensive, especially 
>if you don't save and reuse the state after the three key expansions 
>step in DES.  In addition, I would like to have a key wrapper format
>that is completely independent of the KEK algorithm, soi that I can use
>the same wrapper whether I use DES, RSA, elliptic curves, etc. And
>I don't think you want to propose doing double encryption with an 
>asymmetric cipher!
>
>What I would suggest would be to replace your inner encryption 
>with the equivalent of Output Feedback mode, but using SHA-1
>as the encryption or whitening function, with a random nonce R serving 
>as the starting seed for SHA-1.  
>
>In other words, begin by computing SHA-1(R) of the random nonce, and 
>call that W(1).  Then W(2) = SHA-1(W(1)), and W(n) = SHA-1(W(n-1)),
>where n= length(keyblob + encryption block size)/160 rounded up to 
>the next SHA-1 block boundary, so that any necessary padding is whitened
>as well.
>
>Then XOR the string of W(1)...W(n) with the keyblob KB(1)...KB(n) to 
>produce the whitened plaintext of the keyblob, P(1)...P(n).
>
>Finally, encrypt R || P(1)...P(n) using whatever KEK algorithm is desired.
>
>Now the only question I have is whether the fact that the whitening 
>does not involve the plaintext and is therefore known once the random
>nonce has been decrypted can somehow be used to leak information,
>given partially known plaintext in the keyblob. It would if the nonce weren't
>secret, but in order to gain any information about the nonce would require
>finding a ciphertext block that matches a specific block, corresponding to R, 
>rather than merely finding any two matching blocks.
>
>So I don't see an attack, regardless of the type of KEK encryption algorithm
>used, including both symmetric and asymmetric algorithms. Does anyone else?
>
>I do concede that this approach produces some data expansion -- at least 160 
>bits for the random nonce, and perhaps some more for padding if the keyblob 
>that
>is being encrypted is not an exact multiple of the encryption block size.
>Generally speaking, that is a tradeoff I would be willing to make.
>
>Bob
>
>
>>>> Peter Gutmann <[email-masked]> 02/05/99 02:46AM >>>
>
>[Note: Recipient list trimmed to those who've shown an interest so far]
> 
>Instead of using OAEP-type padding (which is rather complex to implement and 
>results in data expansion), why not just encrypt the wrapped key twice?  This 
>way, the outer encryption layer depends on every bit in the inner encryption 
>layer, and that depends on the plaintext and MEK, so you never get lots of 
>identical messages encrypted with different keys.  This is trivial to 
>implement, requires no extra algorithms beside than the cipher used for the 
>wrapping, and results in no data expansion.  Here's how it works:
> 
>  Notation: 
> 
>  P[] = plaintext blocks
>  C1[], C2[] = ciphertext blocks encrypted once/twice
> 
>  Encryption:
> 
>  Encrypt P[ 0 ]...P[ n ] using the initial IV
>  Encrypt C1[ 0 ]...C1[ n ] using the existing IV from the previous pass 
>        (ie C1[ n ])
> 
>  Decryption:
> 
>  Decrypt C2[ 1 ]...C2[ n ] using C2[ 0 ] as the IV
>  Decrypt C2[ 0 ] using C1[ n ] as the IV
>  Decrypt C1[ 0 ]...C1[ n ] using the initial IV
>
>Peter.
>
>

Date: Thu, 04 Feb 1999 16:18:03 -0500
To: "Bob Jueneman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Bob:

I do not mind if a group goes off and solves the most general problem, but
that is not the problem that I have.

In the S/MIME v3 environment and other environments that use the
Cryptographic Message Syntax (CMS), the KEK and CEK will always be
symmetric keys.  If we could come to closure on one symmetric key wrapping
another symmetric key, it would be very helpful to the S/MIME v3 effort.
In fact, wrapping one 3DES key in another 3DES key is the highest priority,
and wrapping one RC2 key in another RC2 128-bit key is the next highest
priority.

Russ

At 12:57 PM 2/4/99 -0700, Bob Jueneman wrote:
>Peter,
>
>The only [small] problem I have with your approach is performance,
>as double encryption with triple-DES is relatively expensive, especially 
>if you don't save and reuse the state after the three key expansions 
>step in DES.  In addition, I would like to have a key wrapper format
>that is completely independent of the KEK algorithm, soi that I can use
>the same wrapper whether I use DES, RSA, elliptic curves, etc. And
>I don't think you want to propose doing double encryption with an 
>asymmetric cipher!
>
>What I would suggest would be to replace your inner encryption 
>with the equivalent of Output Feedback mode, but using SHA-1
>as the encryption or whitening function, with a random nonce R serving 
>as the starting seed for SHA-1.  
>
>In other words, begin by computing SHA-1(R) of the random nonce, and 
>call that W(1).  Then W(2) = SHA-1(W(1)), and W(n) = SHA-1(W(n-1)),
>where n= length(keyblob + encryption block size)/160 rounded up to 
>the next SHA-1 block boundary, so that any necessary padding is whitened
>as well.
>
>Then XOR the string of W(1)...W(n) with the keyblob KB(1)...KB(n) to 
>produce the whitened plaintext of the keyblob, P(1)...P(n).
>
>Finally, encrypt R || P(1)...P(n) using whatever KEK algorithm is desired.
>
>Now the only question I have is whether the fact that the whitening 
>does not involve the plaintext and is therefore known once the random
>nonce has been decrypted can somehow be used to leak information,
>given partially known plaintext in the keyblob. It would if the nonce weren't
>secret, but in order to gain any information about the nonce would require
>finding a ciphertext block that matches a specific block, corresponding to R, 
>rather than merely finding any two matching blocks.
>
>So I don't see an attack, regardless of the type of KEK encryption algorithm
>used, including both symmetric and asymmetric algorithms. Does anyone else?
>
>I do concede that this approach produces some data expansion -- at least 160 
>bits for the random nonce, and perhaps some more for padding if the keyblob 
>that
>is being encrypted is not an exact multiple of the encryption block size.
>Generally speaking, that is a tradeoff I would be willing to make.
>
>Bob
>
>
>>>> Peter Gutmann <[email-masked]> 02/05/99 02:46AM >>>
>
>[Note: Recipient list trimmed to those who've shown an interest so far]
> 
>Instead of using OAEP-type padding (which is rather complex to implement and 
>results in data expansion), why not just encrypt the wrapped key twice?  This 
>way, the outer encryption layer depends on every bit in the inner encryption 
>layer, and that depends on the plaintext and MEK, so you never get lots of 
>identical messages encrypted with different keys.  This is trivial to 
>implement, requires no extra algorithms beside than the cipher used for the 
>wrapping, and results in no data expansion.  Here's how it works:
> 
>  Notation: 
> 
>  P[] = plaintext blocks
>  C1[], C2[] = ciphertext blocks encrypted once/twice
> 
>  Encryption:
> 
>  Encrypt P[ 0 ]...P[ n ] using the initial IV
>  Encrypt C1[ 0 ]...C1[ n ] using the existing IV from the previous pass 
>        (ie C1[ n ])
> 
>  Decryption:
> 
>  Decrypt C2[ 1 ]...C2[ n ] using C2[ 0 ] as the IV
>  Decrypt C2[ 0 ] using C1[ n ] as the IV
>  Decrypt C1[ 0 ]...C1[ n ] using the initial IV
>
>Peter.
>
>

From: "Linn, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Comments on x942-05 draft
Date: Thu, 4 Feb 1999 16:11:19 -0500 
Sender: [email-masked]

Here's a small set of comments on x942-05, following discussion re x942-04.

In sec. 2.1.2, description of "algorithm": suggest adding the following
sentence at end: "As an implication, it may be appropriate for algorithms
employing variable parameters other than key size to be represented with
different OIDs corresponding to different parameter combinations, if
parameter values cannot be unambiguously determined from usage context".  As
a related point, would it be acceptable to state that the structure of
suppPubInfo may be defined on a per-algorithm basis?   For the case of RC2
usage in S/MIME, where the key length is fixed to 128 bits, it seems to
offer more protective value to represent the variable effective key length
within suppPubInfo than to represent the fixed 128 bit length. 

In 2.1.2, last paragraph, suggest rewriting "the security of the data is
limited ... even if a string longer than ZZ is generated" as "even if a
string longer than ZZ is generated, the effective key space of the KEK is
limited by the size of ZZ, in addition to any security level considerations
imposed by the parameters p and q."

In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m MUST
be >= 160 bits in length". Later in the paragraph, is 160 bits intended as
the appropriate minimum length for p?  (Note, by comparison, that X9.42
requires a multiple of 256 bits with a minimum of 512.)

In 2.3 and 2.4, suggest adding references to [LL97] for discussion of
additional means for generating keys which are not subject to small subgroup
attacks. 

In the last paragraph of security considerations, suggest rewriting in terms
of security levels provided, rather than key sizes required. This makes the
discussion more relevant to particular key sizes selected, rather than
imposing recommended key sizes. In particular, suggest:

The security level provided by these methods depends on several factors. It
depends on the length of the symmetric key (typically, a 2^l security level
if the length is l bits); the size of the prime q (a 2^{m/2} security
level); and the size of the prime p (where the security level grows as  a
subexponential function of the size in bits). A good design principle is to
have a balanced system, where all three security levels are approximately
the same. If many keys are derived from a given pair of primes p and q, it
may be prudent to have higher levels for the primes. In any case, the
overall security is limited by the lowest of the three levels.

Editorial:

In 2.1.1, the description of h says "... h(p-1)/q mod p ..."; should be "...
h^{(p-1)/q} mod p ...".

In 2.2, first paragraph, FIPS-186-1 is cited as [DSS], which doesn't appear
in the references. Given that FIPS-186-1 is currently in a review comment
period, it may be appropriate to shift this citation to point to the
finalized [FIPS-186], as included in the references section.   In the same
paragraph, there's an unmatched opening parenthesis. 

In 2.2, 2nd paragraph, "... consequently, q MUST each be ..." -> "...
consequently, q MUST be ...".

Sec. 2.4 and the security considerations section each have cross-references
as "S" rather than "Section". 

--jl

Date: Thu, 4 Feb 1999 15:26:46 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Last Call Comment on ESS - Signing Certificate Attribute
Sender: [email-masked]

All,

I agree with Jim's proposed change. 

- John Pawling

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: Last Call Comments on CMS-10
Date: Thu, 4 Feb 1999 12:12:50 -0800 
Sender: [email-masked]

OK -- I just consulted my developers.  We do a decode of the entire
SignedData or EnvelopedData object in one shot.  This means that we fail the
decode operation no matter if you put the version in or not.  We just get to
fail faster if you update the version.  Our product does not decode the
structure into pieces and attack the pieces individually.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, February 04, 1999 8:34 AM
To: [email-masked]
Subject: Re: Last Call Comments on CMS-10

Calling all implementors...

The crux of this issue is what S/MIME v2 code will do if it encounters a
version 1 SignedData that contains a SignerInfo with a version other than
1.  Will your implmentation:

	a) fail to parse the ASN.1 and report an error

	b) check the version, skip it, and look for another SignerInfo

	c) die ungracefully
		(if you do not want to admit this publically, please send 
		 private e-mail or use an anonymous service)

Similarly, what will happen if the implementation encounters a version 0
EnvelopedData that contains a RecipientInfo with a version other than 0.
Same three choices.

Russ

Date: Thu, 04 Feb 1999 12:57:30 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Peter,

The only [small] problem I have with your approach is performance,
as double encryption with triple-DES is relatively expensive, especially 
if you don't save and reuse the state after the three key expansions 
step in DES.  In addition, I would like to have a key wrapper format
that is completely independent of the KEK algorithm, soi that I can use
the same wrapper whether I use DES, RSA, elliptic curves, etc. And
I don't think you want to propose doing double encryption with an 
asymmetric cipher!

What I would suggest would be to replace your inner encryption 
with the equivalent of Output Feedback mode, but using SHA-1
as the encryption or whitening function, with a random nonce R serving 
as the starting seed for SHA-1.  

In other words, begin by computing SHA-1(R) of the random nonce, and 
call that W(1).  Then W(2) = SHA-1(W(1)), and W(n) = SHA-1(W(n-1)),
where n= length(keyblob + encryption block size)/160 rounded up to 
the next SHA-1 block boundary, so that any necessary padding is whitened
as well.

Then XOR the string of W(1)...W(n) with the keyblob KB(1)...KB(n) to 
produce the whitened plaintext of the keyblob, P(1)...P(n).

Finally, encrypt R || P(1)...P(n) using whatever KEK algorithm is desired.

Now the only question I have is whether the fact that the whitening 
does not involve the plaintext and is therefore known once the random
nonce has been decrypted can somehow be used to leak information,
given partially known plaintext in the keyblob. It would if the nonce weren't
secret, but in order to gain any information about the nonce would require
finding a ciphertext block that matches a specific block, corresponding to R, 
rather than merely finding any two matching blocks.

So I don't see an attack, regardless of the type of KEK encryption algorithm
used, including both symmetric and asymmetric algorithms. Does anyone else?

I do concede that this approach produces some data expansion -- at least 160 
bits for the random nonce, and perhaps some more for padding if the keyblob that
is being encrypted is not an exact multiple of the encryption block size.
Generally speaking, that is a tradeoff I would be willing to make.

Bob

>>> Peter Gutmann <[email-masked]> 02/05/99 02:46AM >>>

[Note: Recipient list trimmed to those who've shown an interest so far]
 
Instead of using OAEP-type padding (which is rather complex to implement and 
results in data expansion), why not just encrypt the wrapped key twice?  This 
way, the outer encryption layer depends on every bit in the inner encryption 
layer, and that depends on the plaintext and MEK, so you never get lots of 
identical messages encrypted with different keys.  This is trivial to 
implement, requires no extra algorithms beside than the cipher used for the 
wrapping, and results in no data expansion.  Here's how it works:
 
  Notation: 
 
  P[] = plaintext blocks
  C1[], C2[] = ciphertext blocks encrypted once/twice
 
  Encryption:
 
  Encrypt P[ 0 ]...P[ n ] using the initial IV
  Encrypt C1[ 0 ]...C1[ n ] using the existing IV from the previous pass 
        (ie C1[ n ])
 
  Decryption:
 
  Decrypt C2[ 1 ]...C2[ n ] using C2[ 0 ] as the IV
  Decrypt C2[ 0 ] using C1[ n ] as the IV
  Decrypt C1[ 0 ]...C1[ n ] using the initial IV

Peter.

Date: Thu, 04 Feb 1999 12:36:29 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: KEKRecpientInfo KEKIdentifier
Cc: [email-masked]
Sender: [email-masked]

Peter:

Excuse my hasty word choice.  Let me try again.

I believe that the KEKRecpientInfo KEKIdentifier should not be optional.
The decryptor always needs to have a means of identifying which KEK was
used by the encryptor, even if the encryptor and decryptor are the same party.

If CMS is being used to support a file encryption application, I would
expect more that one file-encryption key to be used.  However, one could
imagine a case where files that are not intended to be shared would wrap
those file-encryption keys in the same key-encryption key (KEK).  But,
wait.  There are probably also files that will be shared.  These need a
different KEK.  So, some plaintext data is neede to distinguish these KEKs.
 I suggest that the KEKRecpientInfo KEKIdentifier is a good choice.

If the file encryption application does not support more than one KEK (for
example, no files are shared), then I still see a use for the
KEKRecpientInfo KEKIdentifier.  Two people using this application should
get a reasonable error if they try to dercypt each other's files.  In this
case, the KEKRecpientInfo KEKIdentifier could be the user name or the
application serial number.

Russ

At 01:33 AM 2/5/99 +0000, Peter Gutmann wrote:
>>I believe that the KEKRecpientInfo KEKIdentifier should not be optional. The
>>recipient always needs to have a means of identifying which KEK to use to
>>process the received message.
> 
>Well, that's a good point, and if you were right I'd agree with you.  You're 
>assuming that the only thing CMS will ever be used for throughout its entire 
>existence is handling S/MIME messages ("process the received message").  As I 
>pointed out a few days ago, KEKIdentifier has no known (non-contrived) use
for 
>things like file encryption, which 8 years of experience with PGP indicate 
>would be the most common use for KEKRecipientInfo.  As John Ross
suggested, if 
>it's needed for S/MIME then mandate it in MSG or ESS, but don't force anyone 
>who uses CMS into using it just because S/MIME happens to need it.
> 
>Peter.
> 
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Paul Hoffman (E-mail)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Cc: "Russ Housley (E-mail)" <[email-masked]>
Subject: Last Call Comment on ESS - Signing Certificate Attribute
Date: Thu, 4 Feb 1999 11:24:25 -0800 
Sender: [email-masked]

In reviewing some requirements that are coming from external companies on
our product requirements and I found the following problem.

It turns out that not everybody is up to the point of using attribute
certificates for assigning authorizations.  This information is being
carried in normal authentication certificates and ususally in an encryption
certificate rather than the signing certificate.  This means that we need to
allow more than attribute certificates in the last portion of the list.

Replace Section 5.4 paragraph 4 with the following:

If more than one certificate is present in the sequence of ESSCertIDs, the
certificates after the first one limit the set of authorization certificates
that are used during signature validation. Authorization certificates can be
both attribute certificates and normal certificates. The issuerSerial SHOULD
be
present in these certificates, unless the client who is validating the
signature is expected to have easy access to all the certificates required
for validation. If only the signing certificate is present in the sequence.
there are no restrictions on the set of authorization certificates used in
validating the signature.

jim

Date: Thu, 4 Feb 1999 14:15:28 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: KEKRecpientInfo KEKIdentifier
Sender: [email-masked]

Peter,

If you have multiple KEK keys which could be used to decrypt the file, then
you need to know which one to use.  If there is only one possible KEK key
which could be used to decrypt the file, then I can see your point that the
KEKIdentifier would not be needed to identify which KEK to use.  In summary,
I agree that the KEKIdentifier could be made optional.  

- John

At 01:33 AM 2/5/99, [email-masked] wrote:
>>I believe that the KEKRecpientInfo KEKIdentifier should not be optional. The
>>recipient always needs to have a means of identifying which KEK to use to
>>process the received message.
> 
>Well, that's a good point, and if you were right I'd agree with you.  You're 
>assuming that the only thing CMS will ever be used for throughout its entire 
>existence is handling S/MIME messages ("process the received message").  As I 
>pointed out a few days ago, KEKIdentifier has no known (non-contrived) use for 
>things like file encryption, which 8 years of experience with PGP indicate 
>would be the most common use for KEKRecipientInfo.  As John Ross suggested, if 
>it's needed for S/MIME then mandate it in MSG or ESS, but don't force anyone 
>who uses CMS into using it just because S/MIME happens to need it.
> 
>Peter.
> 
>
>

Date: Thu, 4 Feb 1999 13:26:11 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Last Call Comments on CMS-10
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> I believe that programmers will implement one of the following:
> 
> a) examine the value of the version number and reject (or skip over, if
> applicable) fields with unrecognized syntaxes; or 
> 
> b) ignore the version numbers and just try to decode the object.
> 
> I believe that we should write the specs so that vendors can develop code to
> properly implement option a.

I agree with John and Blake that a mixture of signerInfos should be
allowed in a v1 signedData.  However, I agree with Eric that there
is little practical difference between a) and b).  Decoding until
you come to an unsupported version number should have the identical
behavior as decoding until you come to some unrecognized syntax.

"Jim Schaad (Exchange)" <[email-masked]> writes:
> John and Russ,
> 
> I completely disagree with this.  I don't think that it is any type of a
> fair statement to say that down level clients should be able in any way,
> shape or form to be able to parse one of these new messages.

There are general rules for extensibility which will allow new
features to be incorporated into existing structures without breaking
old software.  X.509 extensions are an example - new extensions can
be defined, and old software either accept or reject certs containing
unrecognized extensions without choking on the ASN.1.  The Certificate
version number doesn't get incremented above v3 every time a new set
of extensions is defined.

IMO, a version number should be incremented only when necessary to
prevent incorrect interpretation of an object.  A version which tries
to capture every detail of the enclosed subfields is unnecessarily
complex and redundant.  It is penny wise and pound foolish, because the
time saved by allowing receivers to do shortcut message rejection on
the outer object is overwhelmed by the complex logic required for
senders to propogate inner contents outward in order to construct
conforming version numbers in the various enclosing objects.

> From: Russ Housley <[email-masked]>
> 
> The crux of this issue is what S/MIME v2 code will do if it encounters a
> version 1 SignedData that contains a SignerInfo with a version other than
> 1.  Will your implmentation:
> 
> 	a) fail to parse the ASN.1 and report an error
> 
> 	b) check the version, skip it, and look for another SignerInfo
> 
> 	c) die ungracefully
> 		(if you do not want to admit this publically, please send 
> 		 private e-mail or use an anonymous service)

Similarly, what will S/MIME v2 code do if it encounters a version 3
SignedData.  If the answer to both questions is a) or c), then that
implementation is too flawed to affect our decision, and can justifiably
be ignored.

Date: Thu, 04 Feb 1999 10:38:44 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Tolga Acar" <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Stephen,

>>> Dr Stephen Henson <[email-masked]> 02/03/99 05:25PM >>>
Apologies if I've missed the point here but...

[RRJ] Me too, as I have not been following the S/MIME - CMS discussion in any
depth, but only seized on the issue of key wrapping as a general problem.
Within Novell's NICI architecture we do lots of key wrapping for purposes that
have nothing to do with S/MIME.  Once the discussion pointed out a potential
weakness in key wrapping generally (and this seems to be just one of a class
of problems that have been uncovered recently, including the SSL million-questions
attack.

Is there some specific need to use the same KEK for mailing lists
multiple times or could the same solution be used as in S-S DH? 

In other words make the use of a "salt" in the message compulsory and
use the mailing list key in place of the DH shared secret (ZZ). This
would then allow the same mailing list key to be used multiple times
because the KEK would be different with each salt.

[RRJ] Rules of thumb are inherently dangerous, but my own preference 
when a problem shows up is to reach for a bigger hammer and try to smash the
problem completely, rather than trying to finesse it. So I'd much rather have a 
generalized key wrapping scheme than one that is tied to S/MIME or even CMS
specifically.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/ 
Email: [email-masked] 
NOTE NEW (13/12/98) PGP key: via homepage.

Date: Thu, 04 Feb 1999 11:34:25 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Last Call Comments on CMS-10
Sender: [email-masked]

Calling all implementors...

The crux of this issue is what S/MIME v2 code will do if it encounters a
version 1 SignedData that contains a SignerInfo with a version other than
1.  Will your implmentation:

	a) fail to parse the ASN.1 and report an error

	b) check the version, skip it, and look for another SignerInfo

	c) die ungracefully
		(if you do not want to admit this publically, please send 
		 private e-mail or use an anonymous service)

Similarly, what will happen if the implementation encounters a version 0
EnvelopedData that contains a RecipientInfo with a version other than 0.
Same three choices.

Russ

Date: Thu, 4 Feb 1999 11:08:31 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Last Call Comments on CMS-10
Sender: [email-masked]

Eric,

You wrote:
>I don't believe that the version number matters here much. The
>way I see it, a client that's smart enough to skip innapropriately
>versioned Signer or RecipientInfos should be smart enough to
>skip over a different CMS version number and see if it can
>really read the message.

I disagree with this statement.  I believe that programmers will implement
one of the following:

a) examine the value of the version number and reject (or skip over, if
applicable) fields with unrecognized syntaxes; or 

b) ignore the version numbers and just try to decode the object.

I believe that we should write the specs so that vendors can develop code to
properly implement option a.

You wrote:
>I tend to agree here. OTOH, if OriginatorInfo is present, then
>it seems that the version number must be increased. Else what
>good is the version number in the first place?

CMS already states that the envelopedData version must be 3 if
originatorInfo is present.

- John Pawling

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Fri, 5 Feb 1999 02:46:22 (NZDT)
Sender: [email-masked]

[Note: Recipient list trimmed to those who've shown an interest so far]
 
Instead of using OAEP-type padding (which is rather complex to implement and 
results in data expansion), why not just encrypt the wrapped key twice?  This 
way, the outer encryption layer depends on every bit in the inner encryption 
layer, and that depends on the plaintext and MEK, so you never get lots of 
identical messages encrypted with different keys.  This is trivial to 
implement, requires no extra algorithms beside than the cipher used for the 
wrapping, and results in no data expansion.  Here's how it works:
 
  Notation: 
 
  P[] = plaintext blocks
  C1[], C2[] = ciphertext blocks encrypted once/twice
 
  Encryption:
 
  Encrypt P[ 0 ]...P[ n ] using the initial IV
  Encrypt C1[ 0 ]...C1[ n ] using the existing IV from the previous pass 
        (ie C1[ n ])
 
  Decryption:
 
  Decrypt C2[ 1 ]...C2[ n ] using C2[ 0 ] as the IV
  Decrypt C2[ 0 ] using C1[ n ] as the IV
  Decrypt C1[ 0 ]...C1[ n ] using the initial IV

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: KEKRecpientInfo KEKIdentifier
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 5 Feb 1999 01:33:38 (NZDT)
Sender: [email-masked]

>I believe that the KEKRecpientInfo KEKIdentifier should not be optional. The
>recipient always needs to have a means of identifying which KEK to use to
>process the received message.
 
Well, that's a good point, and if you were right I'd agree with you.  You're 
assuming that the only thing CMS will ever be used for throughout its entire 
existence is handling S/MIME messages ("process the received message").  As I 
pointed out a few days ago, KEKIdentifier has no known (non-contrived) use for 
things like file encryption, which 8 years of experience with PGP indicate 
would be the most common use for KEKRecipientInfo.  As John Ross suggested, if 
it's needed for S/MIME then mandate it in MSG or ESS, but don't force anyone 
who uses CMS into using it just because S/MIME happens to need it.
 
Peter.

Date: Wed, 03 Feb 1999 21:38:04 -0800
To: Burt Kaliski <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: RE: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Bob Jueneman <[email-masked]>, Tolga Acar <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Ron Rivest <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

At 01:48 PM 2/3/99 -0800, Burt Kaliski wrote:
>Don Johnson's proposal two-pass encryption with triple-DES-CBC is another
>option. It has the advantage of not requiring a separate hash function, and,
>implemented with appropriate settings, resists the birthday attacks on the
>original method.

Burt and Don,

	I'm not sure what Don intended, but I was reminded of one of Ron Rivest's 
papers (in Cryptologia) -- proposing bidirectional encryption when the 
system is easier to break in one direction than the other.

	In the case of CBC mode, one could encrypt a long block twice, as Don 
suggested, but index the blocks in reverse order the second time.  The IV 
could be 0 for both passes.

	I haven't tried analyzing this mode of operation yet, but it has a pleasant 
symmetry.

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     http://www.pobox.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

Date: Thu, 04 Feb 1999 00:25:12 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Apologies if I've missed the point here but...

Is there some specific need to use the same KEK for mailing lists
multiple times or could the same solution be used as in S-S DH? 

In other words make the use of a "salt" in the message compulsory and
use the mailing list key in place of the DH shared secret (ZZ). This
would then allow the same mailing list key to be used multiple times
because the KEK would be different with each salt.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
NOTE NEW (13/12/98) PGP key: via homepage.

Date: Wed, 03 Feb 1999 17:12:33 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Dear Burt --

Very interesting!

Ages ago, I tried to analyze the possibility of a compromise of 
Output Feedback Mode of an extremely long message, but I'd never 
considered the Birthday Attack against a very long CBC encrypted 
message when there was partially known plaintext. So this was eye-opening.

In order to make sure that I understand, let me try to generalize the requirements
and play them back to you for comment.

Ideally, we would like to use a common key wrapping envelop approach
that would be resistant to a broad class of these kinds of attacks, regardless 
of the KEK algorithm type (stream, block, or asymmetric), block size, or key length;
or of the CEK algorithm type, block size, or key length; assuming that there 
may be at least some partially known plaintext in the CEK key itself, in the CEK 
wrapping, or in any padding required because of the structure of the KEK 
algorithm or the CEK itself.

So it shouldn't matter if I am using triple-DES with inner or outer CBC, or RC4 with
112 bits, etc.  It would certainly be dumb, but because of export controls it might 
even be the case that a 2048 RSA key, wrapped in an ASN.1 encoded 
structure, might have to be encrypted in a 40 bit RC2.

The partially known plaintext in the completely general case might come from the salt
(if that were a public or semi-public IV); from the key structure itself, such as the 
parity bits in DES,  the leading byte in RSA, or any ASN.1 wrapper; or from any padding 
that might be required because of the nature of the KEK algorithm.

The length of the key that is being wrapped should be immaterial -- it might even be a 
very long one-time pad, so birthday attacks within the key itself should be considered
in addition to the possibility of birthday attacks against common blocks when the same 
CEK is wrapped multiple times using multiple KEKs.

And the size of salt and/or padding should not be fixed, as it might be necessary to 
deal with KEK algorithms of arbitrary structure, ranging from some 1-bit stream 
cipher such as DES CFB to perhaps a 256 bit AES block.  I wouldn't necessarily 
even assume that the internal blocks were multiples of 8 bits.

Although you only described the possibility of leakage due to known padding values,
I would assume there is also a potential risk due to the structure of the CEK itself, in
particular if the CEK is a natural language password, or if there is internal structure
such as in the case of DES parity bits or an ASN.1 encoded key structure.  We have even encountered a possible requirement that the CEK itself be digitally signed by
the key generation facility in order to support possible key escrow schemes,
with the entire complex key structure presumably being encrypted as an opaque string
by the KEK.  (This is likely to be the case where the application never gets to see 
the key in the clear or know anything about its structure, but only gets a handle to
the key blob.)

My initial thought to address this possibility would be to use a secret salt as the basis
for some internal whitening of the CEK structure itself, extending the salt as necessary
to deal with the length of the CEK, and then to continue that whitening to cover the 
padding information.  This of course assumes that the salt itself is a purely random 
bit string with no internal structure or partially known content, for otherwise the problem becomes circular.

I'm going to have to think a bit more about the inclusion of a key integrity check, but 
I would tend to be opposed. At first glance, at least, this seems similar to the French 
stop-value requirement, and instead of providing any additional form of protection 
it might tend to significantly weaken the key encryption. I would at least whiten the 
key integrity check along with everything else.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> Burt Kaliski <[email-masked]> 02/03/99 02:48PM >>>
Dear Bob --

Let me address your question, and the general situation with triple-DES key
wrapping.

The high-level goal is to wrap an arbitrary length content encryption key
(CEK) with a symmetric key encryption key (KEK).

Wrapping single-block CEKs is straightforward and has an established
precedent, as in the wrapping of single-length DES keys by ECB mode
encryption. But there is no established precedent for wrapping
multiple-block CEKs, as far as I'm aware.

Russ proposed one method, which involved formatting the CEK into a package
of the form

  salt || CEK || ICV || pad

where salt is a random value, ICV is an integrity check on the CEK, and pad
one of a set of known padding values. The package is then encrypted with the
KEK in CBC mode.

My initial "attack" on this approach was based on the observation that since
the pad is known, there is known plaintext for the encryption with the KEK.
This leads to a potential vulnerability when many CEKs are wrapped with the
same KEK, due to the Birthday Paradox. After about 2^32 CEKs (for a 64-bit
block size) it is likely that a block of one wrapped CEK will match a block
of another CEK. If one of the blocks corresponds to the encryption of a
partially known value (e.g., a pad xored with some of the previous
ciphertext), then information about the other block will become known.

This is the same as the problem with 64-bit block ciphers in CBC mode for
message encryption -- after about 2^32 blocks, information about the
plaintext starts to leak.

A simple way to avoid the attack is to limit the number of keys that can be
wrapped with a given KEK. Indeed, S/MIME already limits the number in the
case of Diffie-Hellman-based KEKs, since each KEK is employed only once.
However, in the case of mailing lists, a KEK may be used many times.

But the essential issue is the precedent that S/MIME will set for wrapping
multiple-block CEKs in other systems. I'm concerned that we develop
something robust here, not something that works all right for S/MIME but is
hard to adapt to other systems.

Consider, for historical comparison, the password-based encryption methods
in PKCS #5 v1. They worked fine when DES and MD5 where the algorithms of
choice -- but there was no clear method for extending them to, say,
triple-DES and SHA1. PKCS #5 v2 is clearing up the situation, but in the
interim, there were quite a few alternate approaches, with varying degrees
of security and standarization.

My proposal to Russ was to consider the use of OAEP for processing CEKs
prior to encryption with a block cipher. Although OAEP was first developed
for asymmetric encryption, the construction is not limited to that purpose,
and indeed the security proofs should carry over nicely to wrapping with a
symmetric KEK. OAEP has a built-in integrity check and ensures that every
bit of output depends on every bit of input. It is also quite scalable, and
can accommodate CEKs of any length and arbitrary encryption algorithms.
Further, it builds on an exisiting primitive. One can view OAEP as a way of
preparing keys for wrapping with either symmetric or asymmetric techniques,
which simplifies implementation.

I'll suggest a few specific improvements Russ' OAEP proposal in a separate
message.

Don Johnson's proposal two-pass encryption with triple-DES-CBC is another
option. It has the advantage of not requiring a separate hash function, and,
implemented with appropriate settings, resists the birthday attacks on the
original method.

(BTW, I don't have any proprietary interest in promoting OAEP --- just like
to continue to deploy common primitives rather than defining new ones. HMAC
is another example of something that's gaining use because of its
robustness.)

-- Burt

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]] 
> Sent: 	Tuesday, February 02, 1999 4:55 PM
> To: 	[email-masked]; [email-masked] 
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Bob Jueneman; Tolga Acar; [email-masked];
> [email-masked]; Burt Kaliski; [email-masked];
> [email-masked]; [email-masked]; Ron Rivest; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked] 
> Subject: 	Re: A New Triple-DES Key Wrap Algorithm
> 
> Russ,
> 
> For the benefit of those of us who weren't following the discussion all 
> that closely, could you summarize your original submission (and the 
> rationale behind it), and the attack which Burt Kalisky found against it?
> 
> BTW, that's an impressive cc-list -- almost a crypto who's who. I'd add 
> Hugo Kwrazack and Yair Frankel, and certainly Don Coppersmith, 
> but I don't have their current e-mail addresses.
> 
> Bob
> 
> 
> 
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [email-masked] 
> 1-801-861-7387
> 
> 
> 

To: "Jim Schaad (Exchange)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Last Call Comments on CMS-10
From: EKR <[email-masked]>
Date: 03 Feb 1999 15:35:01 -0800
Lines: 33
Sender: [email-masked]

"Jim Schaad (Exchange)" <[email-masked]> writes:
> John and Russ,
> 
> I completely disagree with this.  I don't think that it is any type of a
> fair statement to say that down level clients should be able in any way,
> shape or form to be able to parse one of these new messages.  This is why
> the MUST occurs in the S/MIME documents.
The problem is that these are combined new and old messages.

> I don't think it is a deficency of a down level client to be able to
> completely fail if the ASN does not completely match to spec, I think this
> is normal.  If a down-level client is not looking at version numbers then it
> will deal with what it deals with, but I think that we need to give them
> help not to kill them selfs.  
I don't believe that the version number matters here much. The
way I see it, a client that's smart enough to skip innapropriately
versioned Signer or RecipientInfos should be smart enough to
skip over a different CMS version number and see if it can
really read the message.

> If you are going to go with this agruement then I want to take you arguement
> to the logical extreme.  The text in section 6.1 should be changed so that
> the version number there does not have anything to do with the version
> numbers in RecipeientInfos.  The same aguements about down-level clients
> appear just as valid here as with SignedData.
I tend to agree here. OTOH, if OriginatorInfo is present, then
it seems that the version number must be increased. Else what
good is the version number in the first place?

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Recips W/Different Params
Date: Wed, 3 Feb 1999 14:46:56 -0800 
Sender: [email-masked]

I think this is a reasonable change to add.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 03, 1999 2:37 PM
To: Ietf-Smime (E-mail)
Subject: CMS: Recips W/Different Params

All,

I believe that the following clarifying text should be appended to CMS
section 12.3.1.1:  "When an EnvelopedData is constructed for sets of
recipients whose public keys have been generated using different D-H
parameters (i.e. p,q,g values), then a separate RecipientInfo
KeyAgreeRecipientInfo field must be constructed for each set of recipients
that possess common D-H parameters.  For example, if a user needs to send an
envelopedData to a set of recipients possessing D-H parameter "set 1" and
another set of recipients possessing D-H parameter "set 2", then the
envelopedData must include one RecipientInfo KeyAgreeRecipientInfo that
includes the recipientEncryptedKeys for the set of recipients possessing D-H
parameter "set 1" and a separate RecipientInfo KeyAgreeRecipientInfo that
includes the recipientEncryptedKeys for the set of recipients possessing D-H
parameter "set 2".  This is needed because the originatorKey will be
different for each of these sets of recipients because the originator uses
the recipient's D-H parameters as part of the process of generating the
originator's ephemeral private-public D-H key pair."

Please note that this is an editorial comment.  It does add to or change any
of the CMS concepts.

=========================================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================

Date: Wed, 3 Feb 1999 17:36:57 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: CMS: Recips W/Different Params
Sender: [email-masked]

All,

I believe that the following clarifying text should be appended to CMS
section 12.3.1.1:  "When an EnvelopedData is constructed for sets of
recipients whose public keys have been generated using different D-H
parameters (i.e. p,q,g values), then a separate RecipientInfo
KeyAgreeRecipientInfo field must be constructed for each set of recipients
that possess common D-H parameters.  For example, if a user needs to send an
envelopedData to a set of recipients possessing D-H parameter "set 1" and
another set of recipients possessing D-H parameter "set 2", then the
envelopedData must include one RecipientInfo KeyAgreeRecipientInfo that
includes the recipientEncryptedKeys for the set of recipients possessing D-H
parameter "set 1" and a separate RecipientInfo KeyAgreeRecipientInfo that
includes the recipientEncryptedKeys for the set of recipients possessing D-H
parameter "set 2".  This is needed because the originatorKey will be
different for each of these sets of recipients because the originator uses
the recipient's D-H parameters as part of the process of generating the
originator's ephemeral private-public D-H key pair."

Please note that this is an editorial comment.  It does add to or change any
of the CMS concepts.

=========================================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================

From: Burt Kaliski <[email-masked]>
To: [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Bob Jueneman <[email-masked]>, Tolga Acar <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Ron Rivest <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: A New Triple-DES Key Wrap Algorithm
Date: Wed, 3 Feb 1999 13:48:55 -0800 
Sender: [email-masked]

Dear Bob --

Let me address your question, and the general situation with triple-DES key
wrapping.

The high-level goal is to wrap an arbitrary length content encryption key
(CEK) with a symmetric key encryption key (KEK).

Wrapping single-block CEKs is straightforward and has an established
precedent, as in the wrapping of single-length DES keys by ECB mode
encryption. But there is no established precedent for wrapping
multiple-block CEKs, as far as I'm aware.

Russ proposed one method, which involved formatting the CEK into a package
of the form

  salt || CEK || ICV || pad

where salt is a random value, ICV is an integrity check on the CEK, and pad
one of a set of known padding values. The package is then encrypted with the
KEK in CBC mode.

My initial "attack" on this approach was based on the observation that since
the pad is known, there is known plaintext for the encryption with the KEK.
This leads to a potential vulnerability when many CEKs are wrapped with the
same KEK, due to the Birthday Paradox. After about 2^32 CEKs (for a 64-bit
block size) it is likely that a block of one wrapped CEK will match a block
of another CEK. If one of the blocks corresponds to the encryption of a
partially known value (e.g., a pad xored with some of the previous
ciphertext), then information about the other block will become known.

This is the same as the problem with 64-bit block ciphers in CBC mode for
message encryption -- after about 2^32 blocks, information about the
plaintext starts to leak.

A simple way to avoid the attack is to limit the number of keys that can be
wrapped with a given KEK. Indeed, S/MIME already limits the number in the
case of Diffie-Hellman-based KEKs, since each KEK is employed only once.
However, in the case of mailing lists, a KEK may be used many times.

But the essential issue is the precedent that S/MIME will set for wrapping
multiple-block CEKs in other systems. I'm concerned that we develop
something robust here, not something that works all right for S/MIME but is
hard to adapt to other systems.

Consider, for historical comparison, the password-based encryption methods
in PKCS #5 v1. They worked fine when DES and MD5 where the algorithms of
choice -- but there was no clear method for extending them to, say,
triple-DES and SHA1. PKCS #5 v2 is clearing up the situation, but in the
interim, there were quite a few alternate approaches, with varying degrees
of security and standarization.

My proposal to Russ was to consider the use of OAEP for processing CEKs
prior to encryption with a block cipher. Although OAEP was first developed
for asymmetric encryption, the construction is not limited to that purpose,
and indeed the security proofs should carry over nicely to wrapping with a
symmetric KEK. OAEP has a built-in integrity check and ensures that every
bit of output depends on every bit of input. It is also quite scalable, and
can accommodate CEKs of any length and arbitrary encryption algorithms.
Further, it builds on an exisiting primitive. One can view OAEP as a way of
preparing keys for wrapping with either symmetric or asymmetric techniques,
which simplifies implementation.

I'll suggest a few specific improvements Russ' OAEP proposal in a separate
message.

Don Johnson's proposal two-pass encryption with triple-DES-CBC is another
option. It has the advantage of not requiring a separate hash function, and,
implemented with appropriate settings, resists the birthday attacks on the
original method.

(BTW, I don't have any proprietary interest in promoting OAEP --- just like
to continue to deploy common primitives rather than defining new ones. HMAC
is another example of something that's gaining use because of its
robustness.)

-- Burt

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]]
> Sent: 	Tuesday, February 02, 1999 4:55 PM
> To: 	[email-masked]; [email-masked]
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Bob Jueneman; Tolga Acar; [email-masked];
> [email-masked]; Burt Kaliski; [email-masked];
> [email-masked]; [email-masked]; Ron Rivest; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: 	Re: A New Triple-DES Key Wrap Algorithm
> 
> Russ,
> 
> For the benefit of those of us who weren't following the discussion all 
> that closely, could you summarize your original submission (and the 
> rationale behind it), and the attack which Burt Kalisky found against it?
> 
> BTW, that's an impressive cc-list -- almost a crypto who's who. I'd add 
> Hugo Kwrazack and Yair Frankel, and certainly Don Coppersmith, 
> but I don't have their current e-mail addresses.
> 
> Bob
> 
> 
> 
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [email-masked]
> 1-801-861-7387
> 
> 
> 

Date: Wed, 3 Feb 1999 15:42:10 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Last Call Comments on CMS-10
Sender: [email-masked]

All,

I respectfully disagree with Jim.  An S/MIME v3 user agent should be allowed
to send a signedData that includes a v1 signerInfo that can be processed by
all S/MIME user agents and a v3 signerInfo that can only be processsed by v3
user agents.    This allows a single message to be sent to all recipients.
Otherwise, the user would need to send two messages:  the old S/MIME v2
message to legacy users and a new S/MIME v3 message to S/MIME v3 users.
This seems unworkable, because how does the originator know what flavor of
software will be used by each recipient. 

Furthermore, an S/MIME v3 user agent should be allowed to send an
envelopedData that includes a v0 RecipientInfo that can be processed by all
S/MIME user agents and a v3 RecipientInfo that can only be processsed by v3
user agents.  The version number of such an envelopedData should be v0.  If
the version number was v3, then the legacy software would reject the
envelopedData even though it includes a v1 ReceipientInfo that it could
process.  This allows a single message to be sent to all recipients.
Otherwise, the user would need to send two messages.  The old S/MIME v2
message to legacy users and a new S/MIME v3 message to S/MIME v3 users.  

I agree with Jim that the rules for setting the signedData and envelopedData
version number must be consistent.  Recommend that the Sec 6.1 text
regarding envelopedData version should be changed as follows:

"version is the syntax version number.  If originatorInfo is
present, then version shall be 2.  If all of the RecipientInfo
structures included have a version other than 0, then the version
shall be 2.  If unprotectedAttrs is present, then version shall be
2.  If originatorInfo is absent, any of the RecipientInfo
structures are version 0, and unprotectedAttrs is absent, then
version shall be 0."

- John Pawling

At 12:13 PM 2/3/99 -0800, Jim Schaad (Exchange) wrote:
>John and Russ,
>
>I completely disagree with this.  I don't think that it is any type of a
>fair statement to say that down level clients should be able in any way,
>shape or form to be able to parse one of these new messages.  This is why
>the MUST occurs in the S/MIME documents.
>
>I don't think it is a deficency of a down level client to be able to
>completely fail if the ASN does not completely match to spec, I think this
>is normal.  If a down-level client is not looking at version numbers then it
>will deal with what it deals with, but I think that we need to give them
>help not to kill them selfs.  
>
>If you are going to go with this agruement then I want to take you arguement
>to the logical extreme.  The text in section 6.1 should be changed so that
>the version number there does not have anything to do with the version
>numbers in RecipeientInfos.  The same aguements about down-level clients
>appear just as valid here as with SignedData.  You should either get none of
>the cake or the entire cake, not just the pieces you happen to like.
>
>jim
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, February 03, 1999 7:59 AM
>To: Ietf-Smime (E-mail)
>Subject: RE: Last Call Comments on CMS-10
>
>
>Blake and friends,
>
>I initially objected to the concept of allowing v1 and v3 signerInfos to
>exist in the same signedData because I believed that the beneift was not
>worth the problems that they will probably cause in legacy S/MIME products.
>I suspect that many legacy products don't check the version number of the
>singerInfo before decoding it.  If they don't check it, then they will
>encounter an ASN.1 decode error when processing a v3 signerInfo which could
>cause unpredictable behavior in the software.  
>
>Upon further reflection, I now agree with Blake.  Potential deficiencies in
>legacy products should not drive the design of the v3 S/MIME specs.  An
>S/MIME v3 user agent should be allowed to send a signedData that includes a
>v1 signerInfo that can be processed by all S/MIME user agents and a v3
>signerInfo that can only be processsed by v3 user agents.  I agree with
>Blake that the version number of such a signedData should be v1.  If the
>version number was v3, then the legacy software would reject the signedData
>even though it includes a v1 signerInfo that it could verify.
>
>This concept raises another issue.  ESS states: "If any of the SignerInfos
>included in a SignedData object include an eSSSecurityLabel attribute, then
>all of the SignerInfos in that SignedData object MUST include an
>eSSSecurityLabel attribute and the value of each MUST be identical."  I
>believe that this statement should be changed to: "If any of the SignerInfos
>included in a SignedData object include an eSSSecurityLabel attribute, then
>all of the SignerInfos (including those marked as v1) in that SignedData
>object MUST include an eSSSecurityLabel attribute and the value of each MUST
>be identical." 
>  
>- John Pawling
>
>
>At 02:53 PM 2/2/99 -0800, Blake Ramsdell wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>> Sent: Tuesday, February 02, 1999 2:43 PM
>>> To: Ietf-Smime (E-mail)
>>> Subject: RE: Last Call Comments on CMS-10
>>> 
>>> I believe that a version 3 SignerInfo MUST cause the parent SignedData
>>> version to be 3.  This strategy allows the receiving software 
>>> to be able to
>>> distinquish between an S/MIME v2 or v3 message by looking at 
>>> the first field
>>> in the signedData.
>>
>>I respectfully disagree -- it is possible to have multiple SignerInfos,
>some
>>of which are v2 and can be processed by a v2 agent.
>>
>>If you reword this to be "if all of the SignerInfos are v3, then the parent
>>SignedData should be version 3" or equivalent verbiage, then I think I'd go
>>along with it.
>>
>>Blake
>>--
>>Blake C. Ramsdell
>>Worldtalk Corporation
>>For current info, check http://www.deming.com/users/blaker
>>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>>
>>
>

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Last Call Comments on CMS-10
Date: Wed, 3 Feb 1999 12:27:48 -0800
Sender: [email-masked]

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, February 03, 1999 11:21 AM
> To: [email-masked]
> Cc: Ietf-Smime (E-mail)
> Subject: RE: Last Call Comments on CMS-10
> 
> Based on John's response, I propose the following text:
> 
> version is the syntax version number.  If no attribute 
> certificates are
> present in the certificates field, the encapsulated content type is
> id-data, and any of the elements of SignerInfos are version 
> 1, then the
> value of version shall be 1.  Alternatively, if attribute 
> certificates are
> present, the encapsulated content type is other than id-data, 
> or all of the
> elements of SignerInfos are version 3, then the value of 
> version shall be 3.

Agree.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Last Call Comments on CMS-10
Date: Wed, 3 Feb 1999 12:13:39 -0800 
Sender: [email-masked]

John and Russ,

I completely disagree with this.  I don't think that it is any type of a
fair statement to say that down level clients should be able in any way,
shape or form to be able to parse one of these new messages.  This is why
the MUST occurs in the S/MIME documents.

I don't think it is a deficency of a down level client to be able to
completely fail if the ASN does not completely match to spec, I think this
is normal.  If a down-level client is not looking at version numbers then it
will deal with what it deals with, but I think that we need to give them
help not to kill them selfs.  

If you are going to go with this agruement then I want to take you arguement
to the logical extreme.  The text in section 6.1 should be changed so that
the version number there does not have anything to do with the version
numbers in RecipeientInfos.  The same aguements about down-level clients
appear just as valid here as with SignedData.  You should either get none of
the cake or the entire cake, not just the pieces you happen to like.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 03, 1999 7:59 AM
To: Ietf-Smime (E-mail)
Subject: RE: Last Call Comments on CMS-10

Blake and friends,

I initially objected to the concept of allowing v1 and v3 signerInfos to
exist in the same signedData because I believed that the beneift was not
worth the problems that they will probably cause in legacy S/MIME products.
I suspect that many legacy products don't check the version number of the
singerInfo before decoding it.  If they don't check it, then they will
encounter an ASN.1 decode error when processing a v3 signerInfo which could
cause unpredictable behavior in the software.  

Upon further reflection, I now agree with Blake.  Potential deficiencies in
legacy products should not drive the design of the v3 S/MIME specs.  An
S/MIME v3 user agent should be allowed to send a signedData that includes a
v1 signerInfo that can be processed by all S/MIME user agents and a v3
signerInfo that can only be processsed by v3 user agents.  I agree with
Blake that the version number of such a signedData should be v1.  If the
version number was v3, then the legacy software would reject the signedData
even though it includes a v1 signerInfo that it could verify.

This concept raises another issue.  ESS states: "If any of the SignerInfos
included in a SignedData object include an eSSSecurityLabel attribute, then
all of the SignerInfos in that SignedData object MUST include an
eSSSecurityLabel attribute and the value of each MUST be identical."  I
believe that this statement should be changed to: "If any of the SignerInfos
included in a SignedData object include an eSSSecurityLabel attribute, then
all of the SignerInfos (including those marked as v1) in that SignedData
object MUST include an eSSSecurityLabel attribute and the value of each MUST
be identical." 
  
- John Pawling

At 02:53 PM 2/2/99 -0800, Blake Ramsdell wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, February 02, 1999 2:43 PM
>> To: Ietf-Smime (E-mail)
>> Subject: RE: Last Call Comments on CMS-10
>> 
>> I believe that a version 3 SignerInfo MUST cause the parent SignedData
>> version to be 3.  This strategy allows the receiving software 
>> to be able to
>> distinquish between an S/MIME v2 or v3 message by looking at 
>> the first field
>> in the signedData.
>
>I respectfully disagree -- it is possible to have multiple SignerInfos,
some
>of which are v2 and can be processed by a v2 agent.
>
>If you reword this to be "if all of the SignerInfos are v3, then the parent
>SignedData should be version 3" or equivalent verbiage, then I think I'd go
>along with it.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

Date: Wed, 03 Feb 1999 14:20:45 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: RE: Last Call Comments on CMS-10
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

Based on John's response, I propose the following text:

version is the syntax version number.  If no attribute certificates are
present in the certificates field, the encapsulated content type is
id-data, and any of the elements of SignerInfos are version 1, then the
value of version shall be 1.  Alternatively, if attribute certificates are
present, the encapsulated content type is other than id-data, or all of the
elements of SignerInfos are version 3, then the value of version shall be 3.

Russ

At 10:58 AM 2/3/99 -0500, John Pawling wrote:
>Blake and friends,
>
>I initially objected to the concept of allowing v1 and v3 signerInfos to
>exist in the same signedData because I believed that the beneift was not
>worth the problems that they will probably cause in legacy S/MIME products.
>I suspect that many legacy products don't check the version number of the
>singerInfo before decoding it.  If they don't check it, then they will
>encounter an ASN.1 decode error when processing a v3 signerInfo which could
>cause unpredictable behavior in the software.  
>
>Upon further reflection, I now agree with Blake.  Potential deficiencies in
>legacy products should not drive the design of the v3 S/MIME specs.  An
>S/MIME v3 user agent should be allowed to send a signedData that includes a
>v1 signerInfo that can be processed by all S/MIME user agents and a v3
>signerInfo that can only be processsed by v3 user agents.  I agree with
>Blake that the version number of such a signedData should be v1.  If the
>version number was v3, then the legacy software would reject the signedData
>even though it includes a v1 signerInfo that it could verify.
>
>This concept raises another issue.  ESS states: "If any of the SignerInfos
>included in a SignedData object include an eSSSecurityLabel attribute, then
>all of the SignerInfos in that SignedData object MUST include an
>eSSSecurityLabel attribute and the value of each MUST be identical."  I
>believe that this statement should be changed to: "If any of the SignerInfos
>included in a SignedData object include an eSSSecurityLabel attribute, then
>all of the SignerInfos (including those marked as v1) in that SignedData
>object MUST include an eSSSecurityLabel attribute and the value of each MUST
>be identical." 
>  
>- John Pawling
>
>
>At 02:53 PM 2/2/99 -0800, Blake Ramsdell wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>> Sent: Tuesday, February 02, 1999 2:43 PM
>>> To: Ietf-Smime (E-mail)
>>> Subject: RE: Last Call Comments on CMS-10
>>> 
>>> I believe that a version 3 SignerInfo MUST cause the parent SignedData
>>> version to be 3.  This strategy allows the receiving software 
>>> to be able to
>>> distinquish between an S/MIME v2 or v3 message by looking at 
>>> the first field
>>> in the signedData.
>>
>>I respectfully disagree -- it is possible to have multiple SignerInfos, some
>>of which are v2 and can be processed by a v2 agent.
>>
>>If you reword this to be "if all of the SignerInfos are v3, then the parent
>>SignedData should be version 3" or equivalent verbiage, then I think I'd go
>>along with it.
>>
>>Blake
>>--
>>Blake C. Ramsdell
>>Worldtalk Corporation
>>For current info, check http://www.deming.com/users/blaker
>>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>>
>>
>

Date: Wed, 03 Feb 1999 12:49:17 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Last Call Comments on CMS-10
Cc: [email-masked]
Sender: [email-masked]

Please excuse my previous posting.  when I did a cut-and-paste from anothe
window, my mail user agent software decided to make it HTML.  Sorry.  Here
is the reply in plain text.

==========

John:

I agree.  How about this for replacement text in section 5.1:

	The fields of type SignedData have the following meanings: 

		version is the syntax version number.  If no attribute 
		certificates are present in the certificates field, the 
		encapsulated content type is id-data, and all elements of 
		SignerInfos are version 1, then the value of version shall 
		be 1.  Alternatively, if attribute certificates are 
		present, the encapsulated content type is other than 
		id-data, or any of the elements of SignerInfos are version 
		3, then the value of version shall be 3.

Russ

Date: Wed, 3 Feb 1999 10:58:58 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Last Call Comments on CMS-10
Sender: [email-masked]

Blake and friends,

I initially objected to the concept of allowing v1 and v3 signerInfos to
exist in the same signedData because I believed that the beneift was not
worth the problems that they will probably cause in legacy S/MIME products.
I suspect that many legacy products don't check the version number of the
singerInfo before decoding it.  If they don't check it, then they will
encounter an ASN.1 decode error when processing a v3 signerInfo which could
cause unpredictable behavior in the software.  

Upon further reflection, I now agree with Blake.  Potential deficiencies in
legacy products should not drive the design of the v3 S/MIME specs.  An
S/MIME v3 user agent should be allowed to send a signedData that includes a
v1 signerInfo that can be processed by all S/MIME user agents and a v3
signerInfo that can only be processsed by v3 user agents.  I agree with
Blake that the version number of such a signedData should be v1.  If the
version number was v3, then the legacy software would reject the signedData
even though it includes a v1 signerInfo that it could verify.

This concept raises another issue.  ESS states: "If any of the SignerInfos
included in a SignedData object include an eSSSecurityLabel attribute, then
all of the SignerInfos in that SignedData object MUST include an
eSSSecurityLabel attribute and the value of each MUST be identical."  I
believe that this statement should be changed to: "If any of the SignerInfos
included in a SignedData object include an eSSSecurityLabel attribute, then
all of the SignerInfos (including those marked as v1) in that SignedData
object MUST include an eSSSecurityLabel attribute and the value of each MUST
be identical." 
  
- John Pawling

At 02:53 PM 2/2/99 -0800, Blake Ramsdell wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, February 02, 1999 2:43 PM
>> To: Ietf-Smime (E-mail)
>> Subject: RE: Last Call Comments on CMS-10
>> 
>> I believe that a version 3 SignerInfo MUST cause the parent SignedData
>> version to be 3.  This strategy allows the receiving software 
>> to be able to
>> distinquish between an S/MIME v2 or v3 message by looking at 
>> the first field
>> in the signedData.
>
>I respectfully disagree -- it is possible to have multiple SignerInfos, some
>of which are v2 and can be processed by a v2 agent.
>
>If you reword this to be "if all of the SignerInfos are v3, then the parent
>SignedData should be version 3" or equivalent verbiage, then I think I'd go
>along with it.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

From: [email-masked]
Date: Wed, 3 Feb 1999 10:44:32 -0500
Subject: Call for Papers: Fourth ACM Workshop on Role-based Access Control
Sender: [email-masked]

CALL FOR PAPERS
Fourth ACM WORKSHOP ON ROLE-BASED ACCESS CONTROL
Date: Oct. 28-29, 1999
Place: George Mason University
url: www.list.gmu.edu/rbac

Sponsored By: ACM Sigsac
Hosted By: George Mason University

The essence of Role-Based Access Control (RBAC) is that permissions
are assigned to roles rather than to individual users.  Users acquire
these permissions by virtue of being authorized to act in these roles.
The driving motivation for RBAC is to simplify security policy
administration while facilitating the definition of flexible,
customized policies.  Basic RBAC models have been successfully applied
since the mainframe era, but emerging systems, which have greater
numbers of users, roles, and systems, challenge the expressive power
of these traditional models.

Workshop Scope:

The ACM workshops on RBAC bring together researchers, developers, and
practitioners to discuss the application of RBAC to both traditional
and emerging systems and the development of new access control
paradigms for future applications.  The workshop invites participation from
the database, network, distributed systems, operating systems, security and
application communities.  Contributions reporting experiences with the
implementation and use of RBAC systems are strongly encouraged.
Attendance is limited to 40 participants to foster a workshop atmosphere.

Topics of interest include, but are not restricted to:

- Modeling and specification of RBAC systems
- Administration of RBAC systems
- RBAC in database security
- Specification and enforcement of security policy
- Delegation and inheritance of access rights in RBAC systems
- Task-based access control and RBAC in collaborative environments
- Application Areas e.g., health-care, WWW
- Support for RBAC in traditional access control systems
- RBAC and organizational control principles
- Experiences with RBAC-based systems; case studies
- Enabling technologies: Java, LDAP, intra-net environments
- Implementation, integration and scalability of RBAC
- End-user tools to support RBAC administration and engineering

Submissions:

Users, developers and researchers are invited to submit seven copies
of their papers (in English and limited to 6000 words) to the Program
Chair at the coordinates given below before the due date.  Submissions can
be either hard copy or electronic (postscript preferred). Papers must be
original and should not be under consideration for publication
elsewhere.  Copyrights for accepted papers must be transferable to ACM
(except for Government work).  Papers will be published by ACM in a
proceedings to be distributed at the workshop and mailed to all SIGSAC
members.  Outstanding papers will be considered for publication in ACM's
new Transactions on Information and Systems Security (TISSEC).

Proposals for panels and group discussions should be sent, preferably
by email, to the Panels Chair at [email-masked].

Paper Submissions should be sent to:
Sylvia Osborn, Program Committee Chair,
Dept. of Computer Science,
The University of Western Ontario,
MC355,
London, Ontario, Canada, N6A 5B7
email: [email-masked]

SCHEDULE:
Papers and Panel Proposals Due: May 15, 1999
Notification of acceptance and advance program: June 30, 1999
Deadline for final version of papers: July 31, 1999
Workshop: October 28-29, 1999

CONFERENCE STEERING COMMITTEE:
Ed Coyne, Science Applications International Corporation
David Ferraiolo, National Institute of Standards and Technology
Trent Jaeger, IBM T.J. Watson Research Center
Sylvia Osborn, The University of Western Ontario
Ravi Sandhu, George Mason University
Charles Youman, Blue Cross Blue Shield

General Conference Chair: Charles Youman, Blue Cross Blue Shield
Local Arrangements: Srinivas Ganta, CygnaCom Solutions Inc.
Program Committee Chair: Sylvia Osborn, The University of Western Ontario
Panels Chair: David Ferraiolo, National Institute of Standards and
Technology
Proceedings Chair: Vijay Atluri, Rutgers University
Publicity Chair: Trent Jaeger, IBM T.J. Watson Research Center

PROGRAM COMMITTEE:

Vijay Atluri, Rutgers University
Dave Ferraiolo, National Institute of Standards and Technology
Luigi Giuri,  Fondazione Ugo Bordoni
Trent Jaeger, IBM T.J. Watson Research Center
Carl Landwehr, U.S. Naval Research Laboratory
Emil Lupu, Imperial College
Ravi Sandhu, George Mason University
Richard Simon
Roshan Thomas, TIS Labs at Network Associates
Dan Thomsen, Secure Computing Corp.
Dan Wallach, Rice University

REGISTRATION:
Information on registration and accommodations will be provided.
There will be a registration fee for all participants to cover meeting
costs.

Date: Wed, 03 Feb 1999 10:23:24 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: RE: Last Call Comments on CMS-10
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

<html>
John:<br>
<br>
I agree.&nbsp; How about this for replacement text in section 5.1:<br>
<font face="Courier New, Courier">
<dl>
<dd>The fields of type SignedData have the following meanings:
<dl>
<dd>version is the syntax version number.&nbsp; If no attribute
certificates are present in the certificates field, the encapsulated
content type is id-data, and all elements of SignerInfos are version 1,
then the value of version shall be 1.&nbsp; Alternatively, if attribute
certificates are present, the encapsulated content type is other than
id-data, or any of the elements of SignerInfos are version 3, then the
value of version shall be 3.<br>
<br>
</font>
</dl>
</dl>Russ<br>
<br>
<br>
<br>
At 05:43 PM 2/2/99 -0500, John Pawling wrote:<br>
&gt;All,<br>
&gt;<br>
&gt;I believe that a version 3 SignerInfo MUST cause the parent
SignedData<br>
&gt;version to be 3.&nbsp; This strategy allows the receiving software to
be able to<br>
&gt;distinquish between an S/MIME v2 or v3 message by looking at the
first field<br>
&gt;in the signedData.<br>
&gt;<br>
&gt;- John Pawling<br>
&gt;<br>
&gt;<br>
&gt;At 02:12 PM 1/12/99 -0800, Jim Schaad (Exchange) wrote:<br>
&gt;&gt;Russ:<br>
&gt;&gt;<br>
&gt;&gt;&gt; -----Original Message-----<br>
&gt;&gt;&gt; From: Russ Housley
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
&gt;&gt;&gt; Sent: Tuesday, January 12, 1999 11:36 AM<br>
&gt;&gt;&gt; To: Jim Schaad (Exchange)<br>
&gt;&gt;&gt; Cc: Ietf-Smime (E-mail)<br>
&gt;&gt;&gt; Subject: Re: Last Call Comments on CMS-10<br>
&gt;<br>
&gt;&lt;snip&gt;<br>
&gt;<br>
&gt;&gt;&gt; &gt;7.&nbsp; Section 5.1: Text on version needs to be
expanded to <br>
&gt;&gt;&gt; deal with SKI.<br>
&gt;&gt;&gt; &gt;Must be 3 if any SignerInfo version is 3.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Are you saying that a version 3 SignerInfo should cause
<br>
&gt;&gt;&gt; parent SignedData<br>
&gt;&gt;&gt; version to be 3?<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Is there a reason to prohibit version 3 SignerInfo from
being <br>
&gt;&gt;&gt; encapsulated in a<br>
&gt;&gt;&gt; version 1 SignedData?<br>
&gt;&gt;<br>
&gt;&gt;This is the backwards compatability thing.&nbsp; Everywhere else
we have done --<br>
&gt;&gt;you get a new version all the way up (See EnvelopedData) if you
do something<br>
&gt;&gt;new on an inner object.&nbsp; This prevents you from starting
something you may<br>
&gt;&gt;regret.&nbsp; If we don't do this here, then I don't see why we
should be doing<br>
&gt;&gt;it in EnvelopedData.&nbsp; I don't care which of the two we
correct, but make<br>
&gt;&gt;them consistant.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; &gt;10. Section 12.3.1, paragraph 3.&nbsp; I would like to
change the <br>
&gt;&gt;&gt; first sentence<br>
&gt;&gt;&gt; &gt;to &quot;A CMS Implementation should support mixed
key-encryption and<br>
&gt;&gt;&gt; &gt;content-encryption algorithms.&quot;<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Disgree.&nbsp; I am reluctant to change &quot;may&quot; to
&quot;should.&quot;&nbsp; What <br>
&gt;&gt;&gt; do other people<br>
&gt;&gt;&gt; think?<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; &gt;11. Section 12.3.3 - Please insert the following
paragraph <br>
&gt;&gt;&gt; in this section<br>
&gt;&gt;&gt; &gt;&quot;&nbsp;&nbsp; A CMS implementation should support
mixed key-encryption <br>
&gt;&gt;&gt; and content-<br>
&gt;&gt;&gt; &gt;&nbsp;&nbsp; encryption algorithms.&nbsp; For example, a
128-bit RC2 <br>
&gt;&gt;&gt; content-encryption<br>
&gt;&gt;&gt; &gt;&nbsp;&nbsp; key may be wrapped with 168-bit Triple-DES
key-encryption key.<br>
&gt;&gt;&gt; &gt;&nbsp;&nbsp; Similarly, a 40-bit RC2 content-encryption
key may be wrapped with<br>
&gt;&gt;&gt; &gt;&nbsp;&nbsp; 128-bit RC2 key-encryption key.&quot;<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; As with comment 10, I would like to hear what other people
<br>
&gt;&gt;&gt; think before<br>
&gt;&gt;&gt; changing &quot;may&quot; to &quot;should.&quot;<br>
&gt;&gt;<br>
&gt;&gt;Can I at least get you to agree to put in the paragraph with the
&quot;may&quot;<br>
&gt;&gt;syntax even if I get no support for &quot;should&quot;?<br>
&gt;&gt;<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; &gt;12. Ditto 11 for section 12.6<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Ditto.&nbsp; As with comments 10 and 11, I would like to
hear what <br>
&gt;&gt;&gt; other people<br>
&gt;&gt;&gt; think before changing &quot;may&quot; to
&quot;should.&quot;<br>
&gt;&gt;&gt; <br>
&gt;&gt;<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Russ<br>
&gt;&gt;&gt; <br>
&gt;&gt;<br>
&gt;&gt;jim<br>
&gt;&gt;<br>
&gt;<br>
</html>

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Last Call Comments on CMS-10
Date: Tue, 2 Feb 1999 14:53:22 -0800
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 02, 1999 2:43 PM
> To: Ietf-Smime (E-mail)
> Subject: RE: Last Call Comments on CMS-10
> 
> I believe that a version 3 SignerInfo MUST cause the parent SignedData
> version to be 3.  This strategy allows the receiving software 
> to be able to
> distinquish between an S/MIME v2 or v3 message by looking at 
> the first field
> in the signedData.

I respectfully disagree -- it is possible to have multiple SignerInfos, some
of which are v2 and can be processed by a v2 agent.

If you reword this to be "if all of the SignerInfos are v3, then the parent
SignedData should be version 3" or equivalent verbiage, then I think I'd go
along with it.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Tue, 2 Feb 1999 17:43:15 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Last Call Comments on CMS-10
Sender: [email-masked]

All,

I believe that a version 3 SignerInfo MUST cause the parent SignedData
version to be 3.  This strategy allows the receiving software to be able to
distinquish between an S/MIME v2 or v3 message by looking at the first field
in the signedData.

- John Pawling

At 02:12 PM 1/12/99 -0800, Jim Schaad (Exchange) wrote:
>Russ:
>
>> -----Original Message-----
>> From: Russ Housley [mailto:[email-masked]]
>> Sent: Tuesday, January 12, 1999 11:36 AM
>> To: Jim Schaad (Exchange)
>> Cc: Ietf-Smime (E-mail)
>> Subject: Re: Last Call Comments on CMS-10

<snip>

>> >7.  Section 5.1: Text on version needs to be expanded to 
>> deal with SKI.
>> >Must be 3 if any SignerInfo version is 3.
>> 
>> Are you saying that a version 3 SignerInfo should cause 
>> parent SignedData
>> version to be 3?
>> 
>> Is there a reason to prohibit version 3 SignerInfo from being 
>> encapsulated in a
>> version 1 SignedData?
>
>This is the backwards compatability thing.  Everywhere else we have done --
>you get a new version all the way up (See EnvelopedData) if you do something
>new on an inner object.  This prevents you from starting something you may
>regret.  If we don't do this here, then I don't see why we should be doing
>it in EnvelopedData.  I don't care which of the two we correct, but make
>them consistant.

>
>> 
>> >10. Section 12.3.1, paragraph 3.  I would like to change the 
>> first sentence
>> >to "A CMS Implementation should support mixed key-encryption and
>> >content-encryption algorithms."
>> 
>> Disgree.  I am reluctant to change "may" to "should."  What 
>> do other people
>> think?
>> 
>> >11. Section 12.3.3 - Please insert the following paragraph 
>> in this section
>> >"   A CMS implementation should support mixed key-encryption 
>> and content-
>> >   encryption algorithms.  For example, a 128-bit RC2 
>> content-encryption
>> >   key may be wrapped with 168-bit Triple-DES key-encryption key.
>> >   Similarly, a 40-bit RC2 content-encryption key may be wrapped with
>> >   128-bit RC2 key-encryption key."
>> 
>> As with comment 10, I would like to hear what other people 
>> think before
>> changing "may" to "should."
>
>Can I at least get you to agree to put in the paragraph with the "may"
>syntax even if I get no support for "should"?
>
>> 
>> >12. Ditto 11 for section 12.6
>> 
>> Ditto.  As with comments 10 and 11, I would like to hear what 
>> other people
>> think before changing "may" to "should."
>> 
>
>> 
>> Russ
>> 
>
>jim
>

Date: Tue, 2 Feb 1999 17:32:21 -0500
To: Russ Housley <[email-masked]>, EKR <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: KEKRecpientInfo KEKIdentifier
Cc: [email-masked], [email-masked]
Sender: [email-masked]

All,

I believe that the KEKRecpientInfo KEKIdentifier should not be optional.
The recipient always needs to have a means of identifying which KEK to use
to process the received message.  

- John Pawling

At 05:17 PM 1/29/99 -0500, Russ Housley wrote:
>What do others think?
>
>I am unwilling to make it optional without a change to MSG that mandates it
>for S/MIME.
>
>Russ
>
>
>At 08:58 AM 1/29/99 -0800, EKR wrote:
>>[email-masked] (Peter Gutmann) writes:
>>> almost never be used in the way you've described.  PGP has worked just fine 
>>> for 8 years without a KEKIdentifier, so I don't see why CMS needs to
>make it 
>>> mandatory.  All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" 
>>and 
>>> you can let the users decide whether it really is essential or not - I'm
>not 
>>> asking that it be removed, simply that it be made optional so you can 
>>leave it 
>>> out where there's nothing to put in a KEKIdentifier.
>>I've got to go with Peter here. While I think that for messaging,
>>the index is more useful, I don't see any harm in making it optional.
>>We can always make MSG require it.
>>
>>-Ekr
>>
>>
>>-- 
>>[Eric Rescorla                                   [email-masked]]
>
>

Posted-Date: Tue, 2 Feb 1999 16:16:41 -0600 (CST)
Date: Tue, 02 Feb 1999 16:11:56 -0600
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Bruce Schneier <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Bob Jueneman" <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 02:55 PM 2/2/99 -0700, Bob Jueneman wrote:
>Russ,
>
>For the benefit of those of us who weren't following the discussion all 
>that closely, could you summarize your original submission (and the 
>rationale behind it), and the attack which Burt Kalisky found against it?
>
>BTW, that's an impressive cc-list -- almost a crypto who's who. I'd add 
>Hugo Kwrazack and Yair Frankel, and certainly Don Coppersmith, 
>but I don't have their current e-mail addresses.
>
>Bob

It is an impressive list, but don't assume that just because someone is on
the 
list that they have analyzed the system.  Russ is looking for free
cryptanalysis,
and the best way to get that is to send email to everyone and hope that
someone
has nothing better to do that day.  It's a good way to have bad systems
broken,
but it is less effective at showing that good systems are actually good.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

Date: Tue, 02 Feb 1999 14:55:08 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Bob Jueneman" <[email-masked]>, "Tolga Acar" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ,

For the benefit of those of us who weren't following the discussion all 
that closely, could you summarize your original submission (and the 
rationale behind it), and the attack which Burt Kalisky found against it?

BTW, that's an impressive cc-list -- almost a crypto who's who. I'd add 
Hugo Kwrazack and Yair Frankel, and certainly Don Coppersmith, 
but I don't have their current e-mail addresses.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> "Don Johnson" <[email-masked]> 02/01/99 01:22PM >>>
Russ,

My comments imbedded in your note and prefixed with an *.
Don J.

Russ Housley <[email-masked]> on 02/01/99 02:48:01 PM

To:   Don Johnson/Certicom
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked] 
Subject:  Re: A New Triple-DES Key Wrap Algorithm

Don:

>1. An integrity value of 16 bits is not enough to thwart a determined
>attacker, especially if using a integrity verification oracle, that is,
>toss values at it until success.

A slight restructuring could lead to 32 bits.  This would eliminate the
Length value and the Pad octet.  Any additional would lead to an additional
block.  This is already six blocks to protect three blocks of data.

* I like the length field, it allows for future flexibility if needed and
is a simple way to strengthen an integrity check.  It is best if the length
field is in a fixed location, that way there is no ambiguity, which as we
know is bad for security.

>2. Given that TDES CBC is being done for messages, why not do two-pass
TDES
>CBC for the key wrapping (that is, do CBC over the key block and then do
it
>again)?  This avoids the need for code for a formatting method.  This
forms
>a block where every bit is dependent on every other bit.  A triple-DES key
>is 168 bits of key; with parity bits, it is 192 bits.  Given a block of
>384, this gives 192 bits for other stuff.  Put in some random bits, put in
>a longer checksum, put in a length of the block,  put in other stuff,
>depending on what attributes are desired.  The TDES blocksize being
>64-bits, text attacks are not relevant as 2**32 blocks of key data will
not
>get encrypted under one set of TDES keys, and as it is random-appearing
>data, is the best thing to encrypt anyway.

Are you saying that the original formatting with double encryption would be
a cheaper way to resolve the problems raised by Burt kaliski?

* I think so or something like that.  I think it would be cheaper in code
size as TDES CBC already needs to exist in the code.

Would the IV
for the second encryption be the ciphertext of the last block from the
first encryption pass?

* Yes.

If so, it needs to be carried somewhere.

* No, it does not, if a 64-bit random number is put first in the block,
this is due to self syncronizing property of CBC mode. Alternately, the
first block could be seen at a random IV.

Is disclosure an issue?

* Not sure what you mean by this.  Please explain more.  Disclosure of the
IV?  Disclosure of the text or key?  What?

Alternatively, can a differnt constant IV be used for
the second pass?

* If you use an IV of 0, the first block is damaged, if you do not care as
it is random, then you do not care.

Thanks for the speedy review,
   Russ

From: "John Ross" <[email-masked]>
To: "EKR" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: KEKRecpientInfo KEKIdentifier
Date: Tue, 2 Feb 1999 16:30:49 -0800
Sender: [email-masked]

I agree it could be optional in CMS.  But  it should be mandated either in
MSG, or it may be better mandated in ESS. For example, ESS could mandate
that the KEKIdentifier must be present when secure mailing lists are used.

Regards

John Ross
-----Original Message-----
From: Russ Housley <[email-masked]>
To: EKR <[email-masked]>
Cc: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Date: Friday, January 29, 1999 2:36 PM
Subject: Re: KEKRecpientInfo KEKIdentifier

>What do others think?
>
>I am unwilling to make it optional without a change to MSG that mandates it
>for S/MIME.
>
>Russ
>
>
>At 08:58 AM 1/29/99 -0800, EKR wrote:
>>[email-masked] (Peter Gutmann) writes:
>>> almost never be used in the way you've described.  PGP has worked just
fine
>>> for 8 years without a KEKIdentifier, so I don't see why CMS needs to
>make it
>>> mandatory.  All you need to do is use "kekid [ 0 ] KEKIdentifier
OPTIONAL"
>>and
>>> you can let the users decide whether it really is essential or not - I'm
>not
>>> asking that it be removed, simply that it be made optional so you can
>>leave it
>>> out where there's nothing to put in a KEKIdentifier.
>>I've got to go with Peter here. While I think that for messaging,
>>the index is more useful, I don't see any harm in making it optional.
>>We can always make MSG require it.
>>
>>-Ekr
>>
>>
>>--
>>[Eric Rescorla                                   [email-masked]]
>

Date: Mon, 01 Feb 1999 14:56:17 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: SecureConnect 2
Sender: [email-masked]

Greetings again. A few of the companies attending SecureConnect 2 have
noted to me that I didn't send mail to the PKIX or S/MIME WG mailing lists.
I guess my non-spam traits got the better of me.

SecureConnect 2 is the interoperability event for S/MIME clients and CAs,
to be held February 23-24. Folks out in The Real World have been finding
that many (but not all) of the interoperability issues in deployed S/MIME
clients are in the certificate handling. Thus, it would be good to get all
of today's S/MIME client vendors and CA vendors together to do more
in-depth testing.

More information on SecureConnect 2 can be found at
<http://www.imc.org/imc-secureconnect/>.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Don Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 1 Feb 1999 15:22:54 -0500
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ,

My comments imbedded in your note and prefixed with an *.
Don J.

Russ Housley <[email-masked]> on 02/01/99 02:48:01 PM

To:   Don Johnson/Certicom
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked]
Subject:  Re: A New Triple-DES Key Wrap Algorithm

Don:

>1. An integrity value of 16 bits is not enough to thwart a determined
>attacker, especially if using a integrity verification oracle, that is,
>toss values at it until success.

A slight restructuring could lead to 32 bits.  This would eliminate the
Length value and the Pad octet.  Any additional would lead to an additional
block.  This is already six blocks to protect three blocks of data.

* I like the length field, it allows for future flexibility if needed and
is a simple way to strengthen an integrity check.  It is best if the length
field is in a fixed location, that way there is no ambiguity, which as we
know is bad for security.

>2. Given that TDES CBC is being done for messages, why not do two-pass
TDES
>CBC for the key wrapping (that is, do CBC over the key block and then do
it
>again)?  This avoids the need for code for a formatting method.  This
forms
>a block where every bit is dependent on every other bit.  A triple-DES key
>is 168 bits of key; with parity bits, it is 192 bits.  Given a block of
>384, this gives 192 bits for other stuff.  Put in some random bits, put in
>a longer checksum, put in a length of the block,  put in other stuff,
>depending on what attributes are desired.  The TDES blocksize being
>64-bits, text attacks are not relevant as 2**32 blocks of key data will
not
>get encrypted under one set of TDES keys, and as it is random-appearing
>data, is the best thing to encrypt anyway.

Are you saying that the original formatting with double encryption would be
a cheaper way to resolve the problems raised by Burt kaliski?

* I think so or something like that.  I think it would be cheaper in code
size as TDES CBC already needs to exist in the code.

Would the IV
for the second encryption be the ciphertext of the last block from the
first encryption pass?

* Yes.

If so, it needs to be carried somewhere.

* No, it does not, if a 64-bit random number is put first in the block,
this is due to self syncronizing property of CBC mode. Alternately, the
first block could be seen at a random IV.

Is disclosure an issue?

* Not sure what you mean by this.  Please explain more.  Disclosure of the
IV?  Disclosure of the text or key?  What?

Alternatively, can a differnt constant IV be used for
the second pass?

* If you use an IV of 0, the first block is damaged, if you do not care as
it is random, then you do not care.

Thanks for the speedy review,
   Russ

Date: Mon, 01 Feb 1999 14:48:01 -0500
To: "Don Johnson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Don:

>1. An integrity value of 16 bits is not enough to thwart a determined
>attacker, especially if using a integrity verification oracle, that is,
>toss values at it until success.

A slight restructuring could lead to 32 bits.  This would eliminate the
Length value and the Pad octet.  Any additional would lead to an additional
block.  This is already six blocks to protect three blocks of data.

>2. Given that TDES CBC is being done for messages, why not do two-pass TDES
>CBC for the key wrapping (that is, do CBC over the key block and then do it
>again)?  This avoids the need for code for a formatting method.  This forms
>a block where every bit is dependent on every other bit.  A triple-DES key
>is 168 bits of key; with parity bits, it is 192 bits.  Given a block of
>384, this gives 192 bits for other stuff.  Put in some random bits, put in
>a longer checksum, put in a length of the block,  put in other stuff,
>depending on what attributes are desired.  The TDES blocksize being
>64-bits, text attacks are not relevant as 2**32 blocks of key data will not
>get encrypted under one set of TDES keys, and as it is random-appearing
>data, is the best thing to encrypt anyway.

Are you saying that the original formatting with double encryption would be
a cheaper way to resolve the problems raised by Burt kaliski?  Would the IV
for the second encryption be the ciphertext of the last block from the
first encryption pass?  If so, it needs to be carried somewhere.  Is
disclosure an issue?  Alternatively, can a differnt constant IV be used for
the second pass?

Thanks for the speedy review,
   Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-x942-05.txt
Date: Mon, 01 Feb 1999 11:54:25 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

Note: This revision reflects comments received during the last call period.

	Title		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-05.txt
	Pages		: 12
	Date		: 29-Jan-99
	
   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
   group. Diffie-Hellman is a key agreement algorithm used by two par-
   ties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is pro-
   vided. The resulting keying material is used as a symmetric encryp-
   tion key.  The D-H variant described requires the recipient to have a
   certificate, but the originator may have a static key pair (with the
   public key placed in a certificate) or an ephemeral key pair.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x942-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-x942-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x942-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x942-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-x942-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Don Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 1 Feb 1999 10:29:14 -0500
Subject: Re: A New Triple-DES Key Wrap Algorithm
Sender: [email-masked]

Russ,

A few comments:
1. An integrity value of 16 bits is not enough to thwart a determined
attacker, especially if using a integrity verification oracle, that is,
toss values at it until success.
2. Given that TDES CBC is being done for messages, why not do two-pass TDES
CBC for the key wrapping (that is, do CBC over the key block and then do it
again)?  This avoids the need for code for a formatting method.  This forms
a block where every bit is dependent on every other bit.  A triple-DES key
is 168 bits of key; with parity bits, it is 192 bits.  Given a block of
384, this gives 192 bits for other stuff.  Put in some random bits, put in
a longer checksum, put in a length of the block,  put in other stuff,
depending on what attributes are desired.  The TDES blocksize being
64-bits, text attacks are not relevant as 2**32 blocks of key data will not
get encrypted under one set of TDES keys, and as it is random-appearing
data, is the best thing to encrypt anyway.

Don Johnson

Russ Housley <[email-masked]> on 01/31/99 06:17:38 PM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked] (bcc: Don
      Johnson/Certicom)
Subject:  A New Triple-DES Key Wrap Algorithm

All:

S/MIME 3 requires a function to encrypt one Triple-DES key in another.
Last March, I proposed an algorithm to wrap a Triple-DES content-encryption
key in a Triple-DES key-encryption key.  With a few minor modifications,
that algorithm was incorporated into the Cryptographic Message Syntax (CMS)
Internet-Draft.  Burt Kaliski recently discovered a flaw in that algorithm.
 In this message I propose a new algorithm.

Here is a summary of how S/MIME v3 will use the function.  The S/MIME v3
originator locally generates a random content-encryption Triple-DES key.
As the name implies, this key will be used to encrypt the message content.
Then, Diffie-Hellman is used to generate a pairwise Triple-DES key with
each message recipient, and the content-encryption key is encrypted under
the pairwise key.

The wrap algorithm is also used to support mail lists.  As setup, a
key-encryption key is distributed to a group of recipients.  Then, the
originator locally generates a random content-encryption Triple-DES key,
and the content-encryption key is encrypted under the pairwise key.  The
key-encryption key could be used for many messages to the group.

Please review the revised algorithm.  Once a key wrap algorithm is
selected, the S/MIME v3 specifications will be ready for review by the
Internet Engineering Steering Group (IESG).  Please do not propose
improvements that are covered by any issued or pending patents.

Thanks for your assistance,
  Russ

- - - - - - - - - -

The Triple-DES key wrap algorithm uses techniques similar to
Bellare-Rogaway Optimal Asymmetric Encryption Padding [OAEP].

X.1  Key Checksum

   The Fletcher checksum algorithm [FLETCHER] is used to provide an
   integrity check value.  The algorithm is:

   1.  Initialize two 16 bit integers, SUM1 and SUM2, to zero.
   2.  Loop through the octets of the content-encryption key, most
       significant (first) octet to least significant (last) octet.
       2a.  Create a 16 bit integer, called TEMP, by concatenating
            eight zero bits and the key octet.
       2b.  SUM1 = SUM1 + TEMP.
       2c.  SUM2 = SUM2 + SUM1.
   3.  Use SUM2 as the 16-bit checksum value.

X.2  Triple-DES Key Wrap

   1.  Adjust the parity bits for each of the three DES keys comprising the
       Triple-DES content-encryption key, call the parity adjusted key CEK.
   2.  Compute an integrity check value on CEK, called ICV, as described
above.
   3.  Let CEKICV = 0x18 || CEK || 0x00 || ICV.
   4.  Generate a 160-bit random value, called RAND.
   5.  Let H1 = SHA-1 ( RAND || 0x01 ).
   6.  Let H2 = SHA-1 ( RAND || 0x02 ).
   7.  Let MASK1 equal the most significant (first) 224 bits of H1 || H2.
   8.  Let MKEY = CEKICV XOR MASK1.
   9.  Let MASK2 = SHA-1 ( MKEY ).
  10.  Let MRAND = MASK2 XOR RAND.
  11.  Let MDATA = MRAND || MKEY.
  12.  Encrypt MDATA with the key-encryption key and CBC mode.  Use an IV
       with each octet equal to 0xA5.  The ciphertext is 384 bits long.

X.3  Triple-DES Key Unwrap

   The key unwrap algorithm is:

   1.  Decrypt the ciphertext using the key-encryption key and CBC mode.
Use
       an IV with each octet equal to 0xA5.
   2.  Decompose the plaintext result.  The most significant (first) 160
bits
       are MRAND, and the remaining 224 bits are MKEY.
   3.  Let MASK2 = SHA-1 ( MKEY ).
   4.  Let RAND = MASK2 XOR MRAND.
   5.  Let H1 = SHA-1 ( RAND || 0x01 ).
   6.  Let H2 = SHA-1 ( RAND || 0x02 ).
   7.  Let MASK1 equal the most significant (first) 224 bits of H1 || H2.
   8.  Let CEKICV = MASK1 XOR MKEY.
   9.  Decompose CEKICV.  The most significant (first) 8 bits are LENGTH,
the
       following 192 bits are CEK, the following 8 bits are PAD, and the
       remaining 16 bits are ICV1.
  10.  If LENGTH is not 0x18, then error.
  11.  If PAD is not 0x00, then error.
  12.  Compute an integrity check value on CEK, called ICV2, as described
above.
  13.  If ICV1 and ICV2 are not equal, then error.
  14.  Check for odd parity of each octet in each DES key that makes up the
       Triple-DES content-encryption key.  If any parity bit is incorrect,
       then error.

REFERENCES

   FLETCHER   Fletcher, J.  "An Arithmetic Checksum for Serial
              Transmissions", IEEE Transactions on Communication,
              Vol. COM-30, No. 1, pp. 247-252, January 1982.

   OAEP       Bellare-Rogaway Optimal Asymmetric Encryption Padding
              { What is the best reference? }

Date: Sun, 31 Jan 1999 18:17:38 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: A New Triple-DES Key Wrap Algorithm
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

All:

S/MIME 3 requires a function to encrypt one Triple-DES key in another.
Last March, I proposed an algorithm to wrap a Triple-DES content-encryption
key in a Triple-DES key-encryption key.  With a few minor modifications,
that algorithm was incorporated into the Cryptographic Message Syntax (CMS)
Internet-Draft.  Burt Kaliski recently discovered a flaw in that algorithm.
 In this message I propose a new algorithm.

Here is a summary of how S/MIME v3 will use the function.  The S/MIME v3
originator locally generates a random content-encryption Triple-DES key.
As the name implies, this key will be used to encrypt the message content.
Then, Diffie-Hellman is used to generate a pairwise Triple-DES key with
each message recipient, and the content-encryption key is encrypted under
the pairwise key.

The wrap algorithm is also used to support mail lists.  As setup, a
key-encryption key is distributed to a group of recipients.  Then, the
originator locally generates a random content-encryption Triple-DES key,
and the content-encryption key is encrypted under the pairwise key.  The
key-encryption key could be used for many messages to the group.

Please review the revised algorithm.  Once a key wrap algorithm is
selected, the S/MIME v3 specifications will be ready for review by the
Internet Engineering Steering Group (IESG).  Please do not propose
improvements that are covered by any issued or pending patents.

Thanks for your assistance,
  Russ

- - - - - - - - - - 

The Triple-DES key wrap algorithm uses techniques similar to 
Bellare-Rogaway Optimal Asymmetric Encryption Padding [OAEP].

X.1  Key Checksum

   The Fletcher checksum algorithm [FLETCHER] is used to provide an
   integrity check value.  The algorithm is:

   1.  Initialize two 16 bit integers, SUM1 and SUM2, to zero.
   2.  Loop through the octets of the content-encryption key, most
       significant (first) octet to least significant (last) octet.
       2a.  Create a 16 bit integer, called TEMP, by concatenating
            eight zero bits and the key octet.
       2b.  SUM1 = SUM1 + TEMP.
       2c.  SUM2 = SUM2 + SUM1.
   3.  Use SUM2 as the 16-bit checksum value.

X.2  Triple-DES Key Wrap

   1.  Adjust the parity bits for each of the three DES keys comprising the
       Triple-DES content-encryption key, call the parity adjusted key CEK.
   2.  Compute an integrity check value on CEK, called ICV, as described above.
   3.  Let CEKICV = 0x18 || CEK || 0x00 || ICV.
   4.  Generate a 160-bit random value, called RAND.
   5.  Let H1 = SHA-1 ( RAND || 0x01 ).
   6.  Let H2 = SHA-1 ( RAND || 0x02 ).
   7.  Let MASK1 equal the most significant (first) 224 bits of H1 || H2.
   8.  Let MKEY = CEKICV XOR MASK1.
   9.  Let MASK2 = SHA-1 ( MKEY ).
  10.  Let MRAND = MASK2 XOR RAND.
  11.  Let MDATA = MRAND || MKEY.
  12.  Encrypt MDATA with the key-encryption key and CBC mode.  Use an IV
       with each octet equal to 0xA5.  The ciphertext is 384 bits long.

X.3  Triple-DES Key Unwrap

   The key unwrap algorithm is:

   1.  Decrypt the ciphertext using the key-encryption key and CBC mode.  Use
       an IV with each octet equal to 0xA5.
   2.  Decompose the plaintext result.  The most significant (first) 160 bits
       are MRAND, and the remaining 224 bits are MKEY.
   3.  Let MASK2 = SHA-1 ( MKEY ).
   4.  Let RAND = MASK2 XOR MRAND.
   5.  Let H1 = SHA-1 ( RAND || 0x01 ).
   6.  Let H2 = SHA-1 ( RAND || 0x02 ).
   7.  Let MASK1 equal the most significant (first) 224 bits of H1 || H2.
   8.  Let CEKICV = MASK1 XOR MKEY.
   9.  Decompose CEKICV.  The most significant (first) 8 bits are LENGTH, the
       following 192 bits are CEK, the following 8 bits are PAD, and the
       remaining 16 bits are ICV1.
  10.  If LENGTH is not 0x18, then error.
  11.  If PAD is not 0x00, then error.
  12.  Compute an integrity check value on CEK, called ICV2, as described
above.
  13.  If ICV1 and ICV2 are not equal, then error.
  14.  Check for odd parity of each octet in each DES key that makes up the
       Triple-DES content-encryption key.  If any parity bit is incorrect,
       then error.

REFERENCES

   FLETCHER   Fletcher, J.  "An Arithmetic Checksum for Serial
              Transmissions", IEEE Transactions on Communication,
              Vol. COM-30, No. 1, pp. 247-252, January 1982.

   OAEP       Bellare-Rogaway Optimal Asymmetric Encryption Padding
              { What is the best reference? }