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@xxxxxxxxxx> on 10/07/2001 08:56:58 PM Please respond to jimsch@xxxxxxxxxx To: ietf-smime@xxxxxxx 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
Attachment:
att1.eml
Description: Binary data