IEEE P1363: Standard for Public-Key Cryptography MINUTES The P1363 working group met at the Harbor Room, University Center, UC Santa Barbara. Tuesday, August 19, 1997. Kaliski held an informational session where he gave a presentation on the P1363 project. Thursday, August 21, 1997 In attendance, we had: Dan Bailey *Lily Chen Whitfield Diffie *Carl Ellison Louis Finkelstein *Walter Fumy Robert Gallant Kris Gaj John Gilmore Adel Jaber *Don Johnson *Burt Kaliski, Chair Shinichi Kawamura John Kennedy Gabe Kostolny *David Kravitz Rob Lambert Anatoly Lebedev Pil Joung Lee Herb Little *Michael Markowitz *Alfred Menezes Francois Morain *Minghua Qu *Leo Reyzin Paul Rubin *Roger Schlafly, Secretary Claus P Schnorr *Jerry Solinas *David Sowinski Ashok Vadekar *Michael Wiener (* = voting member) Kaliski went over the agenda that he had earlier posted to the list. Motion 1. (Solinas, Markowitz). Approve the agenda. Approved by acclamation. Kaliski went over the voting rules. One was eligible to vote if present at this meeting and one of the previous three. We heard officers' reports. Kaliski gave us the agenda and reported on some minor IEEE things. A new draft was posted on the IEEE site, and was circulated at the meeting. It implements decisions of the June meetings; in particular, it has multiple representations for IF private keys and adds X9.31 formatting for use with IFSSA. Markowitz (treasurer) reported that $3910 was sent to Bob Davis, IEEE MSC Treasurer. This was accounted for as follows: 2380 received from John Kennedy (from meetings prior to 11/96) -430 expenses (paid to Crypto '96) 1100 Ft. Meade meeting (11/96) -270 expenses (paid to Jerry Solinas) 600 Auburn meeting (3/97) 180 Konstanz meeting (5/97) (+DM200) 500 Chicago meeting (6/97) -150 withheld for misc. expenses ------ 3910 DM200 collected at the Konstanz meeting must still be converted to dollars and forwarded to the MSC. (The treasurer also notes, with much embarrassment, that he neglected to collect $90 from himself at the March and May meetings.) The fee for the Crypto '97 meeting was set at $20/person for each of the three half days. $1140 was collected. Reyzin is currently acting as editor instead of Yin, but Reyzin is going back to school and Yin is returning from maternity leave. Kaliski raised some technical issues. The first issue was what to do about the second MQV public key being 0 mod 2^h. It was pointed out that it rarely happens, but if it does, the authentication is defeated and the consequences can be very serious. The suggested alternatives to make it nonzero were to add 1, change 0 to 1, look for a nonzero range of h bits, or to add 2^h. One possibility is to terminate the protocol if the reduction mod 2^h is zero. This was rejected because someone might have a public key which is useless for MQV transactions. Another possibility is to define an "MQV key" which is the same as a DH key except that the reduction of the public key mod 2^h is nonzero. Schlafly pointed out that the condition depends on the basis in characteristic two, and hence is subject to what Kaliski called a "chosen basis attack". Once convinced that the problem should not be ignored, Solinas argued for adding 2^h so as to not require any carries. Motion 2. (Solinas, Johnson) Update the MQV primitive to guarantee t and t' being nonzero by adding 2^h after converting to an integer and reducing mod 2^h. Passed, 12-0-2. We took a short break. Kennedy said he will get ANSI to conform to MQV change. Kaliski raised an issue of IF signature with recovery. Reyzin gave a summary: signatures with appendix use x9.31, and signatures with message recovery use iso 9796. One problem was that ISO 9796 uses 6 mod 16 messages, and X9.31 uses 12 mod 16 messages. Hence, the IF signature primitives were generalized for any suitable remainder modulo 16. Johnson wanted to restrict the IF primitive 9.2.7 to r = 6 or 12, since the other cases aren't used. We agree, and also for RW. Solinas talked about small subgroups attacks to DL and EC Diffie-Hellman schemes. The obvious ways to avoid the attacks are: 1. Check that the received public key has order r. 2. Multiply by the cofactor. I.e., raise the shared secret to the power (q-1)/r in the DL case or multiply by #E/r in the EC case. 3. Do nothing, and assume the parties verified the keys in other ways. The DL and EC cases had some separate considerations. In the DL case, the cofactor might be large or small, and there is a user base that is accustomed to ignoring the cofactor. In the EC case, the cofactor is nearly always small, and there are a lot fewer existing users. One common DL case is with a cofactor of 2, so using it would square the DH shared secret. Wiener does not want to have to square because it makes people incompatible. Kravitz comments that when the cofactor is 2, the most information which can be learned by submitting a quadratic non-residue is whether the other user's exponent (as applied to the legitimate generator to create the public key) is odd or even. Motion 3. (Solinas, Kravitz) In EC key exchange, multiply by cofactor to get the shared key. In DL key exchange, leave shared key as is, but have the security notes recommend key validation. Passed, 9-1-3. This leaves the issue of determining the cofactor. The current spec gives an algorithm for it, but it doesn't always work if the cofactor is large. Schlafly argued for putting the cofactor in the EC system parameters. It was not clear whether there was agreement on this point. Solinas said he will look into computing or checking the cofactor in other cases, and volunteered to write up use of weil pairing, if necessary. In the cases where we resist the attack by using the cofactor, we will change the primitive. In the primitive ECSVDP-DH (section 7.2.1), the input W' from the other party might not be a public key as we try to resist that attack. Therefore, the input W' will be described just as a "point on the curve." Johnson was not convinced in EC case. Reyzin complained about the possibility that a primitive will return a error. We put off discussion of how to get cofactor. We adjourned at 5:25 pm. We resumed on Friday, August 22, 1997, at 9am. In attendance: *Lily Chen *Carl Ellison *Walter Fumy Adel Jaber *Don Johnson *Burt Kaliski, Chair *David Kravitz Anatoly Lebedev *Michael Markowitz *Alfred Menezes Francois Morain *Minghua Qu *Leo Reyzin Matt Robshaw *Roger Schlafly, Secretary *Jerry Solinas *David Sowinski *Michael Wiener Tom Wu *Yiqun Lisa Yin (* = voting. We let Yin vote on the theory that her absence in the last few meetings was a maternity leave.) We read the May and June minutes. Kaliski found a minor misspelling, said that his chart of signature schemes in May should have the qualification "that might be considered", and that the June minutes should say that "P. Landrock said in May that ...". Motion 4. (Fumy, Reyzin) Accept the minutes, as amended. Passed, unanimously. Johnson revisited an issue from the day before. He wanted to make the EC cofactor an option. Some users may be able to verify the public key, but not want the extra computation. Schlafly defended requiring the cofactor, saying it is usually very little extra computation for a significant security advantage. Motion 5. (Johnson) Add EC primitive to EC-DH with no cofactor multiplication. Passed, 9-1-3. Kaliski gave a presentation on key derivation, and handed out copies of his slides. He recommends a key derivation function very similar to the HMAC construction where KDF(s,x) = hash(s0, hash(s1,x)). Here s is a shared secret value, x is a key-specific parameter, and s0, s1 are derived from s. This KDF is almost the same as HMAC, except that s is variable length. He cited theoretical work supporting its security, and said it avoids an attack on hash(s,x) which involves appending data to x. Johnson criticizes it, saying that we only need fixed-length inputs, so there is no need for an iterated hash. Wiener favored an option for a massively iterated hash. For example, he might want to iterate a thousand or million times, in order to increase the work load of an attacker. He then left at the 11am break. Johnson proposed using hash(s,x) like X9.42. It does not use fixed- length values for x, but Johnson argued that users might be able to avoid the data-appending attack if they negotiate a length of x depending only on s. Schlafly suggested that we put in a condition which guarantees that the attack is avoided. Motion 6. (Johnson, Reyzin) Put in the X9.42 key derivation function. Passed, 9-1-4. Motion 7. (Ellison, Fumy) Put in an HMAC-like key derivation function. Passed, 10-2-2. Johnson thought the HMAC method is too new, and requires further analysis. Solinas wanted multiple methods in the spec. Other people commented that HMAC is not a new construction. It has been around for two years and has been adopted by some Internet standards. Kaliski talked about signature output formats for DL and EC. The two obvious choices are (1) a raw concatenation of the data, and (2) an ASN.1 "sequence { integer, integer }" as in X9.30. Ellison had his usual objections to ASN.1. Schlafly argued that the ASN.1 is useless in this context, as no part of the signature is meaningful without the whole signature. Motion 8. (Schlafly, Ellison) We define the output signature format to be the raw concatenated form, and skip the ASN.1 format. Passed, 3-2- 8. Schlafly clarified that he was referring to the recommended formats listed in sect. 14, and not prohibiting someone from using X9.30. The X9.30 ASN.1 encoding could still be listed in the ASN.1 appendix that Markowitz promised to do. We took a lunch break. Tom Wu gave presentation on SRP-3, a protocol he is proposing for secure logins. This could be considered in the addendum. Reyzin will post it as a contribution on the P1363 web site. Kaliski reviewed agenda items: - mask generation - output formats IF - naming (skip) - other standards alignment (skip) - annex material conformance ASN.1 key management security notes - addendum strategy - other technical issues (skip) - new work assignments - meeting schedule Kaliski explained his efforts to get a supplement PAR. IEEE New Standards Committee had rejected our addendum PAR at its last meeting. He passed out letters with the rejection, and new proposal for P1363a scope, etc. Schlafly objected that the P1363a purpose and scope is not distinguished very well from P1363. Others said that they intended the P1363a to have the same purpose and scope as P1363, and that we ought to change the P1363 purpose and scope to be more nearly the same as P1363a. Schlafly was baffled as to how we could usefully have two different working groups with the same purpose and scope. Kaliski said the idea was that we could get more alternatives in that way because P1363a could be adding features while P1363 is going to ballot. Schlafly thought this was contrary to what a standard should be, if we are actively adding to it at the same time we are trying to get it approved. Some people wanted to change our current title again. Reyzin said changing the PAR is painful. Motion 9. (Reyzin, Johnson) Change our current title to "Standard Specifications for Public-Key Cryptography, Part 1", and propose a new "Part 2" PAR, subject to Kaliski checking rules on PARs. After some discussion, the motion was withdrawn and replaced. Motion 10. (Reyzin, Johnson) Change the current title to "Standard Specifications for Public-Key Cryptography", and change scope and purpose to something in the spirit of Kaliski's proposed scope and purpose for the new project, apply for a new project "Standard Specifications for Public- Key Cryptography: Additional Techniques", scope and purpose similar, and state that the purpose of the new project is not to interfere with timely development of P1363 and to provide for new ideas with the intent to eventually merge the projects. Passed 10-1-1. We took a short break. Kaliski raised the issue of sponsorship. Kaliski plans to ask the TC Security & Privacy to sponsor us for the new project. They haven't sponsored anyone in a long time, and have a history of some opposition to crypto standards. There may be some political advantage to having a second sponsor, besides the microprocessor standards committee. We talked about possibly splitting the e-mail list into a discussion list and an announcement list. Kaliski will check into whether there are any IEEE conventions for this. The idea is to make the information as broadly and publicly available as possible, but still have a smaller list for detailed discussion of the draft. Kaliski discussed the meeting schedule. The next meeting will be hosted by Certco, Nov. 18-20, Albuquerque, NM. Someone suggested the following meeting after the Feb. 23-26 Anguilla Financial Cryptography conference, but Kaliski said it might be a hassle if there is no local host. Fumy suggested Mar. 3-5 in Boca Raton, as Siemens has a branch there. Kaliski said RSA Labs might be able to host a Boston meeting in May. Next year's Crypto conference in Santa Barbara will have an AES meeting afterwards, possibly interfering with our usual schedule. A teleconference will be scheduled on September 30, 1997. Reyzin talked about conformance, and drew a diagram. Johnson argued for tighter conformance requirements. E.g., what if a box verifies signatures on bogus RSA public keys? We had a long discussion, but Kaliski, Kravitz and Reyzin were happy with the existing model in which conforming implementations are free to accept a set of inputs that is different from what is defined in the primitives, but cannot give a wrong answer for a correct input. It was agreed that more discussion was necessary. Kaliski outlined work remaining for the November meeting. The main items are: Conformance - settle on model, add detail Security notes - review outline, contribute items (probably a full day in Nov.) Body - DH/MQV changes, KDF (editorial), IF output data format, re-review, mask generation field ideas (x9.44 input) Addendum - PARs Annex F - (number theoretic algorithms) minor edits, review, additions from Solinas? Key management - Solinas, Ellison, Kravitz ASN.1 - Markowitz S-expr - Ellison Test vectors - TBD (it would useful if they were available in ascii on the web site) RSA Labs intends to provide test vectors for the IF schemes; it is not clear who will do the other schemes. Motion 11. (Schlafly, Ellison) Adjourn. We adjourned at about 5pm.