Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen

Unofficial translated version of the German Übersicht über geeignete Algorithmen, published on the web pages of the Federal Gazette (www.bundesanzeiger.de) under BAnz AT 27.03.2013 B4 Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen Notification with regard to electronic signatures in accordance with the Electronic Signatures Act and the Electronic Signatures Ordinance (Overview of Suitable Algorithms) Of 18 February 2013 As the competent authority according to section 3 of the Electronic Signatures Act of 16 May 2001 (Federal Law Gazette I p. 876), last amended by Article 4 of the Act of 17 July 2009 (Federal Law Gazette I p. 2091) the Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen has published an overview in the Federal Gazette as required by Annex 1 part I section 2 of the Electronic Signatures Ordinance of 16 November 2001 (Federal Law Gazette I p. 3074), last amended by regulation of 15 November 2010 (Federal Law Gazette I p. 1542), of the algorithms and related parameters deemed suitable for creating signature keys, for hashing data to be signed and for generating and verifying qualified electronic signatures, and the date until which this suitability is pronounced valid. Suitable algorithms in compliance with the requirements of section 17(1) to (3) of the Electronic Signatures Act of 16 May 2001 in conjunction with annex 1 part I section 2 of the Electronic Signatures Ordinance of 16 November 2001 Preliminary remark: As in the preceding years, appropriate algorithms and key-lengths are stated in the following for a period of the next seven years instead of the minimum period of six years as stated in the Electronic Signature Ordinance. In concrete terms, this means that appropriate algorithms and key-lengths are stated until the end of 2019 instead of 2018. Generally long-term prediction is considered to be difficult. The current survey on appropriate algorithms mainly differs from the recently published survey of 30 December 2011 (Federal Gazette No. 10 as of 18 January 2012, page 243) by the introduction of SHA-512/256 defined in [2] as another hash function appropriate for the creation of qualified digital signatures in chapter 2 and by adjustments at various points in chapter 4. The new chapter 7 discusses items in which changes are being considered for future versions of this announcement. This mainly applies to a possible expiration of the suitability of Nyberg- 1

Rueppel signatures in the future. In addition, the planned development of the requirements for random number generation in the context of qualified electronic signatures is discussed in chapter 7. With regard to the possible future expiration of the suitability of Nyberg-Rueppel signatures the Bundesnetzagentur asks for a feedback from users of this method until 30 June 2014. The security of a qualified electronic signature depends primarily on the strength of the algorithms used. The algorithms described in the following are deemed suitable for qualified electronic signatures at least for the next seven years (i.e. until the end of 2019). In addition, recommendations are included which serve to meet future developments in the field of cryptographic algorithms and associated parameters that are emerging now and may even gain in importance in the future. These statements formulated as recommendation serve to "take into account the interest of planning safety of the interested manufacturers, service providers and users" (cf. Roßnagel/Pordesch: Commenting on the Electronic Signatures Act [35]). Up to now there has been no obligation for implementing these recommendations. Apart from recommendations, the algorithm catalogue includes comments that serve for a better understanding and are of purely informative character. The exact bit specifications are set out in the relevant standards of various organisations such as ISO/IEC, NIST and IEEE. These specifications, along with patent-related issues and definitions of the mathematical terms, are not addressed in this account. Information on them can be found in the literature (textbooks, conference proceedings, etc.) and on the Internet. This publication deals with the most important algorithms relevant to practical applications, the cryptographic properties of which can best be assessed on the basis of the results of long years of debate and analysis. The list of algorithms is updated in line with developments in cryptologic research and the experience gained with the practical implementation of signature schemes, and extended as required. The account does not address the security of a specific implementation in hardware and software. This is determined by the procedures referred to in section 15(7) and section 17(4) of the Electronic Signatures Act. 2

Table of Contents TABLE OF CONTENTS 3 1. CRYPTOGRAPHIC REQUIREMENTS 4 1.1. Hash functions 4 1.2. Signature scheme 4 1.3. Key generation 4 2. SUITABLE HASH FUNCTIONS 4 3. SUITABLE SIGNATURE SCHEMES 5 3.1. RSA method 6 3.2. DSA 8 4. GENERATION OF RANDOM NUMBERS 10 5. TIMEFRAME AND PROCESS FOR LONG-TERM SECURE DATA STORAGE 12 6. CRYPTOGRAPHIC ALGORITHMS THAT ARE NO LONGER SUITABLE 12 7. PROSPECTS FOR FUTURE DEVELOPMENTS 16 7.1. Long-term deletion of infrequently used algorithms from the algorithm catalogue 16 7.2. Further development of the requirements for random number generators 16 8. ALGORITHMS DELETED WITHOUT SECURITY REASONS 17 REFERENCES 17 3

1. Cryptographic requirements Under Annex 1 part I section 2 of the Electronic Signatures Ordinance the following algorithms must be determined: An algorithm for hashing data (a hash function), which reduces the data to be signed to a hash, i.e. a bit sequence with a given length. Thus the hash and not the actual data is signed each time. An asymmetric signature scheme consisting of a signing and a verification algorithm. The signature scheme depends on a key pair comprising a private (i.e. secret) key for signing (designated in section 2 subsection 4 of the Electronic Signatures Act as a signature key used to create an electronic signature) and the associated public key for verifying the signature (designated in section 2 subsection 5 of the Act as a signature verification key used to verify an electronic signature). A process for generating key pairs for signature schemes. 1.1. Hash functions The hash of the data is used as a 'digital fingerprint', as it were, in signing and verifying. To prevent a security gap the hash function H must satisfy the following criteria: H must be collision-resistant; i.e. it must be computationally infeasible to find a collision. (Two different digital documents mapped by H to the same hash form a collision). H must be a one-way function; i.e. it must be computationally infeasible to find a preimage for H for a given bit string from the value range. The existence of collisions cannot be avoided. In practice, all that matters is that it is virtually impossible, as said above, to find collisions (and pre-images). 1.2. Signature scheme No one other than the owner of the signature key must be able to create signatures that are rated as valid at a test with the associated signature verification key. In particular, this means that it must be computationally infeasible to calculate the signature key from the (public) verification key. More generally, it must be practically impossible to create valid signatures for new documents knowing the verification key and examples of signatures without using the signature key. 1.3. Key generation The different algorithms require keys with specific properties depending on the relevant scheme. Below further restricting conditions are specified, failure to observe which could result in weaknesses. Additionally it is generally required that keys are generated randomly in accordance with the steps set forth in 4. Generation of random numbers. 2. Suitable hash functions The two hash functions SHA-1 and RIPEMD-160 are only suitable until the end of 2015 for the verification of qualified certificates. 4

The following hash functions of the SHA-2 family members are suitable to ensure long-term security: SHA-256, SHA-512/256, SHA-384, SHA-512 [2]. SHA-256 and SHA-512/256 are hash functions with a hash length of 256 bits, while SHA- 384 and SHA-512 generate hashes with a bit length of 384 respectively 512 bits. SHA- 512/256 corresponds to SHA-512 with a hash value truncated to 256 bits and an initialisation vector defined differently than for SHA-512. SHA-512/256, SHA-384 and SHA-512 are almost identical in terms of their implementation and hence in all implementation aspects (e.g. performance on different platforms). An equal resistance to classical generic attacks on collision resistance and one-way properties is expected for SHA-512/256 as for SHA-256. Due to the larger internal state and the increased number of rounds of SHA-512/256 as compared to SHA-256, a slightly improved margin of safety against future cryptanalytic progress is expected. Another theoretical advantage over SHA-256 is an improved resistance to multi-collision attacks as described in [36]. These four hash functions are (at least) suitable in the coming seven years, i.e. until the end of 2019, for application in qualified electronic signature procedures. The hash function SHA- 224 [2] is suitable for application in qualified electronic signatures until the end of 2015. The table below summarises the suitability of the hash functions. Table 1: Suitable hash functions suitable until the end of 2015 suitable until the end of 2019 SHA-224, (SHA-1, RIPEMD-160) * SHA-256, SHA-384, SHA-512, SHA-512/256 * only for the verification of qualified certificates but not for the generation and verification of other qualified signed data. SHA-1 was approved until the end of 2010 for the generation of qualified certificates, provided that randomness corresponding to at least 20 bits of entropy was used in the generation of the serial number. Even if there is no need for this according to current understanding when using the SHA-2 family, it is nevertheless recommended as an additional safety measure to do the same in this case as well. Comment: Whether at least 20-bit entropy is provided for the generation of a qualified certificate cannot be determined in the context of verifying the qualified certificate by means of a signature application component according to section 2 subsection 11 b of the Electronic Signatures Act. The requirement has rather to be met by the certification provider by operational measures. 3. Suitable signature schemes In 1977, Rivest, Shamir and Adleman explicitly described the RSA method [9] named after them for generating and verifying digital signatures. In 1984, ElGamal [8] proposed another signature scheme. A variant of the ElGamal scheme is the Digital Signature Standard (DSS) [1] published by the National Institute of Standards and Technology (NIST) which specifies 5

the Digital Signature Algorithm (DSA). There are also variants of DSA based on point groups E(K) of elliptic curves over finite fields K, where K is either the field of integers modulo a prime p or a finite field of characteristic 2. The following signature schemes are suitable to meet the requirements of section 17(1) to (3) of the Electronic Signatures Act: 1. RSA [21], 2. DSA [1], [4], 3. DSA variants based on elliptic curves: EC-DSA [1], [4], [5], [10], EC-KCDSA, EC-GDSA [4], Nyberg-Rueppel signatures [6]. For other (non-normative) information about ECDSA and ECGDSA see also sections 4.2.1 and 4.2.2 of [37]. Respectively, the security of these methods is based on: 1. the factorisation problem for integers, 2. the problem of computing discrete logarithms in the multiplicative group of F p or 3. the discrete logarithm problem in an elliptic curve over the field of integers modulo a prime number p or a field of characteristic 2. In order to define the size of system parameters required to ensure the security of these methods, the best known algorithms for factoring integers and calculating discrete logarithms (in the above groups) must be observed and the capability of today's computer technology taken into account. A forecast for the future development of these two aspects is also required, cf. [12], [26], [35], to be able to make an assessment of security for a given period in the future. Such forecasts are only meaningful for relatively short periods (and may of course turn out to be wrong at any time due to unforeseen developments). In the following we assume the bit length r of a number x > 0 to be the integer r with the property 2 r 1 x < 2 r. The security of these methods is ensured (at least) for the next seven years, i.e. until the end of 2019, if the parameters are selected as follows. 3.1. RSA method The parameter n must have a length of at least 1976 bits. 2048 bits are recommended. The table below summarises the minimum bit lengths. Table 2: Suitable key lengths for RSA method Parameter \ period up to the end of 2019 n 1976 (minimum) 2048 (recommended) 6

The prime factors p and q of n should have the same order of magnitude, but not be too close together: ε 1 < log 2 (p) log 2 (q) < ε 2. As a basis for the values ε 1 and ε 2 we suggest ε 1 0.1 and ε 2 30. The prime factors p and q must be generated randomly and independently of one another, observing the given constraints. The public exponent e is selected subject to the constraint ggt(e, (p 1)(q 1)) = 1 independent of n. The associated secret exponent d is then calculated as a function of the predetermined e, so that ed 1 mod kgv(p 1, q 1). It is highly recommended to select e 2 16 + 1. Remarks: In light of the best factorisation algorithms known today there seems to be no longer any good reason why p and q have to be strong prime numbers (i.e. p-1 and q-1 have large prime factors, etc.). The public exponent e can be selected randomly. On the other hand, the advantage of small public exponents is that the signature can be verified very quickly. The method required here (first, selection of e, then selection of d) is meant to ensure that small private exponents will not be chosen, see for instance [18]. In [3], Table 3-2, an upper and lower limit is specified for 2048-bit RSA for e. (2 16 + 1 e < 2 256 ). The hash must be formatted to the bit length of the modulus before the secret exponent d is applied. The formatting process must be selected carefully, see [13]. Until 2019 appropriate processes are: RSA: "Signature Schemes with Appendix" PSS from [14] parts 8.1 and 9.1, DSI according to ISO/IEC 9796-2 with random number [15], digital signature scheme 2 and digital signature scheme 3 from [19]. The RSA formatting scheme: Signature Schemes with Appendix PKCS#1-v1_5 from [14] part 8.2 and 9.2 is suitable until the end of 2015. In addition, the PKCS#1-v1_5 format is suitable for certificate signatures until the end of 2017. But it is recommended not to use it after the end of 2013. The evidentiary value of the generated signatures holds until the end of 2019. Comment: The implementation of the formatting method e.g. how the tasks are divided between the smart card on which exponentiation is carried out with the private key, and the background system is entirely relevant for the security and must be covered by the examination of qualified electronic signature products as provided for by section 15(7) and section 17(4) of the Electronic Signatures Act. 7

See e.g. [1] and [5] for generation of the prime factors. In particular, the possibility of p or q being in fact composite must be ruled out with sufficient probability when a probabilistic primality test is used. As the upper bound of this probability, the value 2 100 (see [1]; but also compare [5] and [16]) is recommended. 3.2. DSA p has to be at least 2048 bits in length. Until the end of 2015 the bit length of parameter q must be at least 224 bits. From the beginning of 2016 at least 256 bits are required for q. The table below summarises the DSA bit lengths. Table 3: Suitable key lengths for DSA Parameter \ period up to the end of 2015 up to the end of 2019 p 2048 2048 q 224 256 Remarks: See [1] for the generation of p and the other parameters; from the beginning of 2010 the probability that p or q are composite should be less than 2 100. Concrete values for the bit lengths of p and q are given in FIPS-186 [1]. Relatively short bit lengths of parameter q allow the construction of collisions in the sense of Vaudenay [11] during parameter generation. These collisions have no significance in the practice of qualified signatures, however. If, notwithstanding this observation, the possibility of constructing such collisions is to be ruled out in general, q must be higher than the maximum hash value. 3.2.a) DSA variants based on groups E(F p ) To define system parameters, an elliptic curve E and a point P are generated on the basis of E(F p ), so that the following conditions apply: We have ord(p) = q with a prime number q differing from p. For r 0 = min(r : q divides p r 1) we get r 0 > 10 4. The class number of the maximal order of the endomorphism ring of E is at least 200. For parameter p there are no restrictions. q must have a minimum bit length of 224 bits, and from the beginning of 2016 a minimum of 250 bits are required for q. The table below summarises the bit lengths of DSA variants based on groups E(F p ) Table 4: Suitable key lengths for DSA variants in E(F p ) Parameter \ period up to the end of 2015 up to the end of 2019 p no restriction no restriction 8

q 224 250 Remarks: The lower bound for r 0 is intended to rule out attacks based on embeddings of the subgroup generated by P into the multiplicative group of a field F p r. Normally (with random selection of the elliptic curve) this estimate is fulfilled, since r 0 is the order of p (mod q) in F q * and thus generally even has the same order of magnitude as q. Ideally r 0 should be determined explicitly, although this requires the somewhat complex factorisation of q 1. By comparison r 0 > 10 4 can be verified much more quickly and is considered adequate in this context. For further explanations on the requirements and sample curves, see [20] and [23]. The hashes must, if their bit length exceeds that of q, be shortened to the bit length of q. For this purpose [10] a suitable number of lower-order bits is truncated. See also the corresponding comment in the next section. With regard to "collisions" as defined in [11], the remarks formulated in Section 3.2 for DSA apply here as well. 3.2.b) DSA variants based on groups E(F 2 m) To define system parameters, an elliptic curve E and a point P are generated on the basis of E(F 2 m), so that the following conditions apply: m is prime. E(F 2 m) cannot be defined over F 2 (i.e. the j-invariant of the curve is not in F 2 ). We have ord(p) = q with q prime. For r 0 = min(r : q divides 2 mr -1), we have r 0 > 10 4. The class number of the maximal order of the endomorphism ring of E is at least 200. There will no longer be any conditions on the parameter m. From the beginning of 2016 at least 250 bits are required for q. The table below summarises the bit lengths of DSA variants based on groups E(F 2 m). Table 5: Suitable key lengths for DSA variants in elliptic curves over fields of characteristic 2 Parameter \ period up to the end of 2015 up to the end of 2019 m no restriction no restriction q 224 250 Remarks: 9 With regard to the 'collisions' defined by [11] mentioned earlier, the same applies to methods based on elliptic curves as to DSA.

If, when calculating the second signature component s, the bit length of the hash value is higher than the bit length of the module q, any supernumerary low-value (right) bits of the hash value will be cut off in [10]. This applies to DSA and DSA variants based on groups E(F p ) or E (F 2 m). The selection of particular, specific parameters for DSA and elliptic curves could possibly lead to the method being weaker than with random choice of parameters. No matter how serious such a threat is thought to be, the planting of weak parameters can be prevented by using a suitable one-way function (i.e. one of the hash functions listed above) to define the parameters and delivering them with a reproducible calculation of the corresponding kind. Concrete proposals are set out in [1], [10], [20] and [23]. The guideline [28] (annex to [29]) defines minimum requirements with regard to the resistance of implementations of elliptic curves over F p against side channel attacks. 4. Generation of random numbers Random numbers are required for the generation of system parameters for signature processes and key generation. For DSA-type signature methods a new random number is needed each time a signature is generated. Appropriate random number generators must be used for this purpose. The former mathematical-technical annexes [30] and [31] in AIS 20 [7] and/or AIS 31 [17] were replaced by the mathematical-technical annex [32] in September 2011. The functionality classes relevant for the algorithm catalogue were mainly retained (under a new name), and new functionality classes have been added, including hybrid deterministic random number generators (functionality class DRG.4) and hybrid physical random number generators (functionality class PTG.3). In addition to random number generators which are evaluated according to the new evaluation criteria [32], those random number generators that have been evaluated according to the old evaluation criteria may continue to be used. Where relevant for the algorithm catalogue, the following table compares the old functionality classes with the new functionality classes. These are not exactly 1-1 relationships, because the requirements of functionality classes are very similar but not identical. The requirements for the new functionality classes are more farreaching in some aspects. Table 6: Comparison of old and new functionality classes for random generators according to AIS20/31 new functionality class [32] old functional class [30] and/or [31] PTG.2 P 2 PTG.3 DRG.2 DRG.3 DRG.4 no counterpart K3 K4 no counterpart Remarks: 10

Hybrid random number generators combine security features of deterministic and physical random number generators. The security of a hybrid deterministic random number generator of the class DRG.4 is based primarily on the complexity of the deterministic part, which belongs to class DRG.3. While using the random number generator, new randomness is repeatedly added. This can be done (for example) at regular intervals or at the request of an application. In addition to a strong noise source, hybrid physical random number generators of class PTG.3 have strong cryptographic post-processing with memory. PTG.3 represents the strongest functionality class in [32]. Conformity to functionality class PTG.3 can be achieved with a PTG.2 compliant random number generator with suitable cryptographic post-processing with memory (see [32], Section 4.5, paragraph 304 and item PTG 3.6 in FCS_RNG 1.1, paragraph 305). Physical random number generators are generally considered appropriate if they belong to one of the following categories: Physical random number generators o new: PTG.2, PTG.3 o old: P2 high Deterministic random number generators o new: DRG.3, DRG.4 with at least 100 bit seed entropy (see [32], paragraph 248, and also [32], paragraph 332, in particular, the last line of Table 12) o old: K4 high with 100 bit seed entropy For the generation of ephemeral keys (DSA, ECDSA, ECGDSA, ECKDSA) it is additionally recommended to choose a random number generator that belongs to one of the following classes: PTG.3, DRG.3, DRG.4 or K4 high with 100 bit seed entropy (cf. [28]). The background is that random numbers that were created by PTG.2-compliant or P2-compliant random number generators may display for example certain biases. There are currently no known attacks that could make use of this. Instead, this is a security measure on principle. Certification service providers are recommended to use a random number generator of class PTG.3. To generate qualified electronic signatures (no certificate signatures), a deterministic random number generator of class DRG.2 or K3 high can be used, if the applicant can reasonably justify that the absence of the DRG.3-specific or the K4-specific property (enhanced backward secrecy) does not imply any additional security risks in the planned use cases. A seed entropy of at least 100 bits must be ensured in this case as well (see [32], section 248 and 332 as above). If the requirements for the random number generators are not met, the corresponding method for the qualified electronic signature must be regarded as potentially insecure. 11

Extensive experience is required before a meaningful assessment of a random number generator can be made. The Federal Office for Information Security (BSI) has just such experience. It is recommended to make use of the expertise of the Federal Office for Information Security (BSI), if required. In conclusion, it can be said that a seed entropy of at least 100 bits is mandatory for all deterministic random number generators. 120 bits seed entropy is recommended for all deterministic random number generators. Remarks: 12 Signature keys, ephemeral keys and primes (for RSA) shall be derived from the generated random numbers using appropriate algorithms (as to elliptic curves, see [28], sections 5.2 and 5.5.1). Simply put, a potential attacker should have as little information about the derived values (to be kept secret) as possible. Ideally, all values within the respective permissible value range shall occur with the same probability, and various random numbers should have at least no practically exploitable correlations. Just as the signature algorithms, the generation of signature keys, ephemeral keys and prime numbers can also be the target of side channel attacks ([27], [28] etc.). This aspect is addressed explicitly in [32]. Also with regard to implementation attacks hybrid random number generators combine safety properties of deterministic and physical random number generators. 5. Timeframe and process for long-term secure data storage In order for a qualified electronic signature to maintain its evidentiary value and to remain reliably verifiable even after the period of validity of an algorithm on which the security of the signature is based has been exceeded, appropriate measures have to be taken as provided in section 17 of the Electronic Signatures Act prior to the end of this period. This includes qualified time stamps that are created in good time prior to the expiry of this period, the security of which is based on algorithms which remain valid in the longer term. Prior to expiry of the validity period of an algorithm upon the security of which such a qualified time stamp is based, this time-stamp must again be provided with a longer-term time stamp with qualified security and so on. The technical guideline [34] deals with the long-term preservation of the evidentiary value of cryptographically signed documents. Instead of generating a time stamp for each individual datum with a qualified electronic signature, it would be more efficient to generate a single qualified time stamp for several sets of electronic data with qualified electronic signatures. An appropriate method for this is the generation of so-called evidence records for qualified electronic signatures according to [22]. When generating evidence records of this kind, among other things a hash tree is generated. Both collision resistance and one-way property are required for the hash function used for this. The same algorithms as for the generation of qualified electronic signatures are suitable here. The validity periods are also identical. 6. Cryptographic algorithms that are no longer suitable All cryptographic algorithms with key lengths and parameter values, which were ever suitable for the creation of qualified electronic signatures and qualified certificates and which have lost this suitability meanwhile, are listed in this section. These algorithms are still needed to

verify signatures or certificates. For this purpose, these algorithms must be supported by the signature application components. The following tables show the last point in time when the particular algorithm with the specified key length and parameter size was considered suitable for the generation of qualified electronic signatures and qualified certificates and/or a transition period ended. (Transition periods of 3 respectively 6 months were granted for RSA 1024, SHA-1.) For hash functions, the points in time when suitability for verification of qualified electronic certificates expires are also specified, i.e. until shortly before that time no measure according to section 5 is necessary to preserve the evidentiary value of qualified certificates. All other data, however, no longer have a valid qualified electronic signature, unless appropriate measures have been taken to preserve the evidentiary value of the signatures prior to expiration of the specified validity periods. 13

Hash functions Table 7: No longer suitable hash functions Hash function suitable until SHA-1 end of June 2008* end of 2010** end of 2015*** RIPEMD-160 end of 2010 end of 2015*** * January - June 2008: Transitional period ** Only for the generation of qualified certificates (in 2010, also on condition of 20 bits of entropy in the serial number) *** Only for the verification of qualified certificates RSA Table 8: No longer suitable RSA key lengths Module length n suitable until 756 end of 2000 1024 end of march 2008* 1280 end of 2008 1536 end of 2009 1728 end of 2010 * January - March 2008: Transitional period DSA Table 9: No longer suitable DSA parameters Parameter p Parameter q suitable until 1024 160 end of 2007 1280 160 end of 2008 1536 160 end of 2009 2048 160 end of 2009 14

DSA variants based on groups E(F p ) Table 10: No longer suitable EC parameters over F p Parameter p Parameter q suitable until no restriction 160 end of 2006 192 180 end of 2009 DSA variants based on groups E(F 2 m) Table 11: No longer suitable EC parameters over binary fields Parameter m Parameter q suitable until No restriction 160 end of 2006 191 180 end of 2009 15

7. Prospects for future developments In this chapter we will briefly discuss the future development of this notification. On the one hand, this section is intended to increase the planning safety for users, certification service providers and hardware and software manufacturers for the creation and verification of electronic signatures and, on the other hand, to allow the above mentioned groups to give feedback at an early stage on planned changes in subject notification. 7.1. Long-term deletion of infrequently used algorithms from the algorithm catalogue It is intended in the future to withdraw algorithms the suitability for creating qualified electronic signatures, even in the absence of known security weaknesses, if it is assumed that the methods do not have any or almost any practical significance. This measure is based on the general consideration that these algorithms generally have been or are examined much less intensively by means of cryptanalysis, than is the case for algorithms that actually are widely applied. This process will in no case lead to the removal of an algorithm before expiry of the validity periods given in the notification. Furthermore, the deletion of an algorithm for such reasons will be announced with a lead time of about 18 months to provide the public with the opportunity to comment on it. Algorithms, which were decided to be deleted, will be listed in section 8 of this notification in the future. Currently, it is considered to terminate the following procedure in this way: Nyberg-Rueppel signatures [6], [19]. Past, present, and (potential) future users of Nyberg-Rueppel signatures will be asked for feedback on this to the Bundesnetzagentur (Federal Network Agency) and the Bundesamt für Sicherheit in der Informationstechnik (Federal Office for Information Security) by 30 June 2014, more specifically to the following two addresses: Bundesnetzagentur Referat IS 15 Postfach 8001 D-55003 Mainz E-Mail: qes@bnetza.de Bundesamt für Sicherheit in der Informationstechnik Referat K22 Postfach 200363 D-53133 Bonn E-Mail: algokat@bsi.bund.de 7.2. Further development of the requirements for random number generators In terms of the requirements for the random number generators, the following further developments are planned: 16 Migration to the functional classes PTG.3 and DRG.4 is aimed at in the medium term. Starting with the next algorithm catalogue, only random number generators shall be considered suitable that are compliant with the new functionality classes of AIS 20

and AIS 31 beyond the year 2019. Exemptions are possible for systems that are already in use. Such exemptions will mainly be considered for systems with a high number of signature cards with a lifecycle beyond 2019 being in circulation already and will affect cards issued to end users before 2014. Provided that suitable products are available, it is planned, starting from the next algorithm catalogue, o to make functionality class PTG. 3 or at least DRG. 4 generally mandatory for certification service providers for the generation of ephemeral keys and for the generation of long-term keys of the provider. The planned regulation shall not affect the residual validity periods of already existing systems of the certification service provider, but it shall immediately apply to systems to be newly certified. It is intended not to extend the suitability of solutions based on random number generators of other classes than PTG.3 or DRG.4 beyond the year 2019 for all certification service providers. o not to extend, in general, the functionality classes P2 high (old) and PTG.2 beyond 2019, at least for the generation of ephemeral keys. Deviations from this are allowed only in justified exceptional cases. These exemptions can result for example from established protective regulations for systems already in use. The content of such exemptions will depend on the application considered. 8. Algorithms deleted without security reasons No procedures previously suitable for the creation or verification of digital electronic signatures have been, or are to be, deleted from the list of suitable procedures without any security concerns being raised. References [1] NIST: FIPS Publication 186-3: Digital Signature Standard (DSS), June 2009 [2] NIST: FIPS Publication 180-4: Secure Hash Standard (SHS), March 2012 [3] NIST: W. Polk, D. Dodson, W. Burr, H. Ferraiolo, D. Cooper, Special Publication 800-78-2: Cryptographic Algorithms and Key Sizes for Personal Identity Verification, Dezember 2010 [4] ISO/IEC 14888-3:2006 Information technology Security techniques Digital signatures with appendix Part 3: Discrete logarithm based mechanisms, 2006 (ersetzt entsprechende Inhalte von ISO/IEC-14888-3:1998) [5] IEEE P1363: Standard specification for public key cryptography, 2000 [6] ISO/IEC 9796-3:2006 Information technology Security techniques Digital Signature schemes giving message recovery Part 3: Discrete logarithm based mechanisms, 2006 (ersetzt ISO/IEC 9796-3:2000) [7] AIS 20: Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Version 2.0, 19.09.2011, https://www.bsi.bund.de/shareddocs/downloads/de/bsi/zertifizierung/interpretatione n/ais20_pdf.pdf 17

[8] T. ElGamal: A public key cryptosystem and a signature scheme based on discrete logarithms, Crypto 84, LNCS 196, S. 10-18, 1985 [9] R. Rivest, A. Shamir, L. Adleman: A method for obtaining digital signatures and public key cryptosystems, Communications of the ACM, vol. 21 no. 2, 1978 [10] ANSI X9.62:2005 Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), 2005. (replacing ANSI X9.62-1998) [11] S. Vaudenay: Hidden collisions in DSS, Crypto 96, LNCS 1109, S. 83-88, 1996 [12] A.K. Lenstra, E.R. Verheul: Selecting Cryptographic Key Sizes, J. Cryptology 39, 2001 [13] J. S. Coron, D. Naccache, J. Stern: On the Security of RSA padding. Crypto 99, LNCS 1666, 1999 [14] PKCS #1 v2.1: RSA Cryptographic Standard, 14.6.2002 [15] DIN V66291: Spezifikation der Schnittstelle zu Chipkarten mit Digitaler Signatur-Anwendung/Funktion nach SigG und SigV, Annex A, 2.1.1, 2002 [16] ANSI X9.31:1998 Digital signatures using reversible public key cryptography for the financial services industry (rdsa), 1998 [17] AIS 31: Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Version 2.0, 19.09.2011, https://www.bsi.bund.de/shareddocs/downloads/de/bsi/zertifizierung/interpretatione n/ais31_pdf.pdf [18] D. Boneh, G. Durfee: Cryptanalysis of RSA with private key d less than N 0.292. Eurocrypt '99, LNCS 1592, 1999 [19] ISO/IEC 9796-2:2010 Information technology Security techniques Digital Signature schemes giving message recovery Part 2: Integer Factorization based mechanisms, 2010 [20] ECC Brainpool (Editor: M. Lochter): ECC Brainpool Standard Curves and Curve Generation, v. 1.0 (19.10.05), http://www.ecc-brainpool.org/download/bp-kurvenaktuell.pdf; Curve parameters as binary files: http://www.ecc-brainpool.org/ecc-standard.htm [21] ISO/IEC 14888-2:2008 Information technology Security techniques Digital signatures with appendix Part 2: Integer factorization based mechanisms, 2008 (replacing corresponding contents in ISO/IEC-14888-3-1998) [22] IETF: RFC 4998, Evidence Record Syntax (ERS) Standards Track, August 2007, http://www.ietf.org/rfc/rfc4998.txt [23] IETF: RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, March 2010, http://www.ietf.org/rfc/rfc5639.txt [24] Electronic signature framework act (Signaturgesetz SigG), Signature Act of 16 May 2001 (Federal Law Gazette I, page 876), last amended by Article 4 of the Act of 17 July 2009 (Federal Law Gazette I, page 2091). See also http://www.nrca-ds.de [25] Digital Signature Ordinance (Signaturverordnung SigV), Signature Ordinance of 16 November 2001 (Federal Law Gazette I, page 3074), last amended by the Ordinance of 15 November 2010 (Federal Law Gazette I, page 1572). See also http://www.nrca-ds.de 18

[26] J. W. Bos, M. E. Kaihara, T. Kleinjung, A. K. Lenstra, P.L. Montgomery: On the Security of 1024-bit RSA and 160-bit Elliptic Curve Cryptography (version 2.1, 01.09.2009), http://eprint.iacr.org/2009/389 [27] T. Finke, M. Gebhardt, W. Schindler: A New Side-Channel Attack on RSA Prime Generation. CHES 2009, LNCS 5747, 2009 [28] W. Killmann, T. Lange, M. Lochter, W. Thumser, G. Wicke: Minimal Requirements for Evaluating Side-Channel-Attack Resistance of Elliptic Curve Implementations. Guideline, https://www.bsi.bund.de/shareddocs/downloads/en/bsi/zertifierung/interpretation/e CCGuide.pdf? blob=publicationfile [29] AIS 46: Informationen zur Evaluierung von kryptographischen Algorithmen und ergänzende Hinweise für die Evaluierung von Zufallszahlengeneratoren. Version 1 (22.10.2010), https://www.bsi.bund.de/shareddocs/downloads/de/bsi/zertifizierung/interpretatione n/ais_46_1_pdf.pdf [30] W. Schindler: Functionality Classes and Evaluation Methodology for Deterministic Random Number Generators. Version 2.0, 02.12.1999, former mathematical-technical annex to AIS 20, https://www.bsi.bund.de/shareddocs/downloads/en/bsi/zertifierung/interpretation/a IS20_Functionality_Classes_Evaluation_Methodology_DRNG.pdf [31] W. Killmann, W. Schindler: A proposal for: Functionality classes and evaluation methodology for true (physical) random number generators. Version 3.1, 25.09.2001, former mathematical-technical annex to AIS 31, https://www.bsi.bund.de/shareddocs/downloads/en/bsi/zertifierung/interpretation/a IS31_Functionality_classes_evaluation_methodology_for_true_RNG.pdf [32] W. Killmann, W. Schindler: A proposal for: Functionality classes for random number generators. Version 2.0, 18.09.2011, mathematical-technical annex to AIS 20 and AIS 31, https://www.bsi.bund.de/shareddocs/downloads/en/bsi/zertifierung/interpretation/a IS20_Functionality_classes_for_random_number_generators.pdf and https://www.bsi.bund.de/shareddocs/downloads/en/bsi/zertifierung/interpretation/a IS31_Functionality_classes_for_random_number_generators.pdf [33] A. Roßnagel (Hrsg.): Recht der Multimedia-Dienste, Kommentar zum Informationsund Kommunikationsdienste-Gesetz und Mediendienste-Staatsvertrag, Beck Verlag, München 1999 [34] BSI Technical Guideline 03125: TR-ESOR Beweiswerterhaltung kryptographisch signierter Dokumente, Version 1.1, 18.02.2011, https://www.bsi.bund.de/shareddocs/downloads/de/bsi/publikationen/technischeric htlinien/tr03125/bsi_tr_03125_v1.1.pdf [35] A. K. Lenstra: Key Lengths, in: H. Bigdoli (Editor): Handbook of Information Security, John Wiley & Sons, 2006 [36] A. Joux: Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions, Crypto 2004, LNCS 3152, S. 306-316 [37] BSI, Technical Guideline TR 03111: Elliptic Curve Cryptography, Version 2.0, 19

28.6.2012, https://www.bsi.bund.de/shareddocs/downloads/en/bsi/publications/techguidelines/ TR03111/BSI-TR-03111_pdf.pdf Mainz, 18 February 2013 IS 15 Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway By order of Schwemmer 20