1. 1 Workshop on algorithms and parameters for Electronic Signatures November 25, 2004. Brussels

2. 2 Algorithms and parameters for Electronic Signatures Two parts: –Part 1: Hash functions and asymmetric algorithms –Part 2: Symmetric algorithms and protocols for secure channels

3. 3 Part 1: Hash functions and asymmetric algorithms 4.Maintenance of the document 5.Hash functions –5.1. General –5.2. Recommended one way hash functions 6.Signature algorithms –6.1. General –6.2. Recommended signature algorithms 7.Signature suites –7.1.General –7.2. Padding methods –7.3. Recommended signature suites

4. 4 Part 1: Hash functions and asymmetric algorithms 8. Recommended key pair generation methods –8.1. General –8.2. Recommended key pair generation methods 9. Random number generation methods –9.1. General –9.2. Recommended random number generation methods 10. Recommended hash functions and key sizes versus time –10.1. Liberal view –10.2. Conservative view –10.3. Recommended hash functions versus time –10.4. Recommended key sizes versus time

5. 5 Part 1: Hash functions and asymmetric algorithms 11. Practical ways to identify hash functions and algorithms –11.1 Functions and algorithms identified using OIDs –11.2 Functions and algorithms identified using URNs –11.3 Functions and algorithms with no OID –11.4 Functions and algorithms with no URN 12. Algorithms in the context of Advanced Electronic Signatures –12.1 Time period resistance of hash functions and keys 12.1.1 Time period resistance for hash functions 12.1.2 Time period resistance for signer’s key 12.1.3 Time period resistance for root keys 12.1.4 Time period resistance for other keys –12.2 Algorithms for the various data structures

6. 6 Part 1: Hash functions and asymmetric algorithms Annex A (normative): Updating algorithms and parameters –A.1 Introduction –A.2 Maintenance Process Annex B (informative): Recommended key sizes (historical) Annex C (informative): Generation of RSA keys for signatures –C.1 Generation of random prime numbers –C.2 Generation of RSA modulus –C.3 Generation of RSA keys Annex D (informative): Generation of elliptic curve domain parameters –D.1 ECDSA and ECGDSA based on a group E(F p ) –D.2 ECDSA and ECGDSA based on a group E(F 2 m )

7. 7 Part 1: Hash functions and asymmetric algorithms Annex E (informative): On the generation of random data –E.1 Classes of random number generators –E.2 On tests for NRNGs Annex F (informative) Algorithms identifiers defined in various documents Annex G (informative): Explanatory text about the “liberal view” and the “conservative view –G.1 Estimates based on past experience –G.2 Estimates based on power of computation –G.3 Recommended key sizes and use dates drawn from past estimates –G.4 Recommended key sizes and use dates drawn from Lenstra and Verheul’s table

8. 8 Part 2: Symmetric algorithms and protocols for secure channels Secure messaging for smart cards –5.1 General –5.2 Channel keys establishment 5.2.1Authentication steps 5.2.2Session Key creation 5.2.3Compute channel key 5.2.4.Compute send sequence counter SSC –5.3 Secure Messaging Mode 5.3.1.CLA byte 5.3.2.TLV coding of command and response message 5.3.3.Treatment of SM-Errors 5.3.4.Padding for checksum calculation

9. 9 Main points of discussion from SAGE meeting (1/2) The criteria we mention (secure/commonly used/easily referenced) was generally agreed to be OK. There was some concern about the Whirlpool algorithm not being well studied enough. There was a question about why we have not included SHA- 512. There were some concerns raised about whether the German elliptic curve variants were well enough studied. They had been “approved” by the BSI on some level. There were several suggestions regarding the key lengths. The most significant is that 640 be changed to 768 for the 3 year predictions in Table 8, and the inclusion of 163 for ecdsa in the bottom two rows of the same table.

10. 10 Main points of discussion from SAGE meeting (2/2) The insertion of a statement as to why we haven’t distinguished between the use of algorithms in various contexts. About Annex G: some editing out of the original text has been done in this annex, taking out some of the argumentation as to why we prefer the Lenstra/Verheul arguments to the extrapolation methods. The point was raised that this original argumentation should either be included in its entirety, completely left out or replaced with a much shorter explanatory text.

11. 11 Question 1 from Helmut Biely The title of chapter 11 of -1 is "Practical ways to identify...". Is this the only purpose of this chapter of the ensuing chapters on OID's ? The real question is whether such OID's are there : –for interoperability purposes only, or/and –to identify the algos, that are considered as sufficiently secure by this TS.

12. 12 Question 2 from Helmut Biely The OID for ECDSA in 11.1.2 : –RFC 3278 is used (and not 3279 !) as reference. –However, RFC 3278 (applying to CMS only) sets the parameters part of the ASN.1 SEQUENCE explicitly to NULL, i.e no curve is defined, as is necessary for a complete OID e.g. in an X509 certificate. –Now, does this mean, that all curves defined in X9.62 are covered by the TS, whereas other curves are outside ? –Are there any intentions to differentiate between curves (e.g. for interoperability reasons) or do no such plans exist ?

13. 13 Questions from Franco Ruggieri The questions are addressed in the original document.