Hi Jim,
I suggest the following answers to your questions, in the case
of HMAC-SHA1 and CMS-3DES-WRAP.
1. We should specify the HMAC-SHA1 key size to be 160 bits (the
strength of HMAC-SHA1).
2. When wrapping with 3DES, a 192-bit key is expected, so pad with
the HMAC-SHA1 key 32 zero bits (which gives an equivalent 192-bit
HMAC-SHA1 key).
3. No.
These answers need adjustments for other key wrap and
MAC algorithms.
Reasoning and further details are given below.
Recall that, as Simon, Paul and I noted in our Internet-Draft "Use of
ECC Algorithms in S/MIME", if AuthenticatedData uses two or more
RecipinientInfo's, then there is a serious problem. Say R1 and
R2 are the recipients, the message is M and the MAC key is K. Since
R2 receives K, receiver R2 can use it to compute MAC_K(M') for a bogus
message M' and then send a bogus AuthenticatedData to R1, using the
Wrap_R1(K) already present in the original AuthenticatedData. R1
would think M' originated from the sender even though it originated
from R2. Once R2 sees K and Wrap_R1(K), R2 can repeat this attack as
often as necessary. Thus, our I-D recommends just one RecipientInfo
per AuthenticatedData.
Now, a similar attack might apply if a weak MAC key is used. In an
extreme case, suppose a sender S sends an AuthenticatedData to a
receiver R using a 1-bit MAC key. An adversary A knowing about the
1-bit key can guess the MAC key, confirm its guess, and then launch
the above attack. This works no matter how strong the key management
and wrap algorithms, because A knows once K and Wrap_R(K), A can send
any message to the receiver R in an AuthenticatedData appearing to be
from S.
If 10-bit MAC key is used, then the attacker has to guess 512 MAC keys
on average. If a 40-bit MAC key is used, the sender must guess 2^39
MAC keys on average. Although it is probably impractical, once the
guess is made, the attacker can forge as many AuthenticatedData's as
desired. Thus the effective strength of AuthenticatedData is limited
by the smallest MAC key size used.
In fact, in the multi-user setting where 40-bit MAC keys are used,
after about 2^20 messages, one expects identical MAC keys to have been
used. This might also lead to problems.
Thus, I think a minimum HMAC-SHA1 key length should be set. Perhaps
80 bits is enough, but I don't know. Clearly, 160 bits would be
safer.
The minimum key size should be a MUST or SHOULD for the sender.
I realize some implementations may prefer a 128-bit key generator, but
this might be a little low.
It could be a SHOULD for the receiver, except that one has to be careful about
ascertaining the length of the key. Suppose the sender selects a
random 160 bit key K, but due to pure chance, the last 8 bits are
zero. This could happen with 1 in 256 chance. Should the receiver
reject this because it looks like a small key (152 bits)? Probably
not.
One possible exception to the minimum could be the following. If a
key-wrap algorithm Wrap40 only supports 40 bits, then a 40-bit
HMAC-SHA1 K40 could be used. The guessing attack can still be
launched, but all the forged AuthenticatedData's would contain K40 and
Wrap40(K40). It does not seem possible to generate Wrap192(K40), so
the attack does not allow forgery of high-strength AuthenticatedData's
(assuming the wrap algorithm is secure).
My preference would be adapt such a Wrap40 to allow wrapping of
longer MAC keys using 40bit encryption.
Finally, larger key sizes would not hurt, but do not seem to help,
according to the RFC on HMAC-SHA1. Key sizes 193-512 cannot be
wrapped with the current 3DES algorithm, but key sizes 513 and larger
can be because they are hashed to 160 bits first accoring to the
way HMAC-SHA1 is defined.
Thanks,
Dan
"Jim Schaad" <jimsch(_at_)nwlink(_dot_)com> on 10/07/2001 08:56:58 PM
Please respond to jimsch(_at_)exmsft(_dot_)com
To: ietf-smime(_at_)imc(_dot_)org
cc: (bcc: Daniel Brown/Certicom)
Subject: Questions on AuthenticatedData
I have just started an implemenation for AutenticatedData and have the
following questions:
1. Should we specify a suggested size for the randomly generated secret
to be used for HMAC-SHA1? (The size for HMAC-3DES is fixed at the size
of a 3DES key.)
2. What key wrap algorithm should I use for wrapping the secret for an
HMAC-SHA1 secret? I can see myself generating a 512 bit secret for the
MAC operation, now I need to wrap it in a 3DES, RC2 or AES key. What is
the proper way of doing this?
3. Does the answer for 2 imply that we want the lengths for 1 to be the
length of a defined content encrytion algorithm key?
Jim
att1.eml
Description: Binary data