1 / 13

Workshop on algorithms and parameters for Electronic Signatures

Workshop on algorithms and parameters for Electronic Signatures. November 25, 2004. Brussels. Algorithms and parameters for Electronic Signatures. Two parts: Part 1: Hash functions and asymmetric algorithms Part 2: Symmetric algorithms and protocols for secure channels.

vala
Télécharger la présentation

Workshop on algorithms and parameters for Electronic Signatures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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. 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. 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. 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(Fp) • D.2 ECDSA and ECGDSA based on a group E(F2m)

  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. Part 2: Symmetric algorithms and protocols for secure channels • Secure messaging for smart cards • 5.1 General • 5.2 Channel keys establishment • 5.2.1 Authentication steps • 5.2.2 Session Key creation • 5.2.3 Compute 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. 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. 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. 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. 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. Questions from Franco Ruggieri • The questions are addressed in the original document.

More Related