final report of european project number ist-1999-12324 ... · new european schemes for signatures,...

Draft

April

19, 2

004Final report of European projectnumber IST-1999-12324, named

New European Schemes forSignatures, Integrity, andEncryption

April 19, 2004— Version 0.15 (beta)

Springer-Verlag

Berlin Heidelberg NewYorkLondon Paris TokyoHongKong BarcelonaBudapest

Draft

April

19, 2

004

Draft

April

19, 2

004

The work described in this report has been supported by the Commission ofthe European Communities through the IST program under contract IST-1999-12324. The information in this document is provided as is, and no warranty isgiven or implied that the information is fit for any particular purpose. The userthereof uses the information at its sole risk and liability.

B. Preneel1, A. Biryukov1, C. De Cannière1, S. B. Örs1,E. Oswald1,8, B. Van Rompay1,

L. Granboulan2, E. Dottax2, G. Martinet2,S. Murphy3, A. Dent3, R. Shipsey3, C. Swart3, J. White3,

M. Dichtl4, S. Pyka4, M. Schafheutle4, P. Serf4,E. Biham5, E. Barkan5, Y. Braziler5, O. Dunkelman5,

V. Furman5, D. Kenigsberg5, J. Stolin5,J-J. Quisquater6, M. Ciet6, F. Sica6,

H. Raddum7, L. Knudsen7,9, M. Parker7.

1 Katholieke Universiteit Leuven, Dept. Elektrotechniek-ESAT/SCD-COSIC, Kasteel-park Arenberg 10, B-3001 Leuven-Heverlee, Belgium

2 École Normale Supérieure, Département d’Informatique, 45 rue d’Ulm, Paris 75230Cedex 05, France

3 Royal Holloway, Information Security Group, Egham, Surrey TW20 0EX, UK4 Siemens AG, Otto-Hahn-Ring 6, 81739 München, Germany5 Technion, Computer Science Dept., Haifa 32000, Israel6 Université catholique de Louvain, UCL Crypto Group, Laboratoire de Microélectron-

ique (DICE), Place du Levant 3, B-1348 Louvain-la-Neuve, Belgium7 Universitetet i Bergen, Dept. of Informatics, PO Box 7800 Thormoehlensgt. 55,

Bergen 5020, Norway8 A-SIT, Technologiebeobachtung, Inffeldgasse 16a, A-8010 Graz, Austria9 Tech. U. of Denmark, Dept.of Mathematics, Building 303, DK-2800 Lyngby, Denmark

Draft

April

19, 2

004

Draft

April

19, 2

004

Table of Contents

Book I. An Introduction to the NESSIE Project

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32. NESSIE Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94. Security Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115. Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136. Selection for the 2nd Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157. Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198. Dissemination and Standardization . . . . . . . . . . . . . . . . . . . . 219. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Book II. Evaluation

Part A. Submitted primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271. Call for Cryptographic Primitives . . . . . . . . . . . . . . . . . . . . . 292. The submissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Part B. Security evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492. Block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553. Stream ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514. Hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715. Message authentication codes . . . . . . . . . . . . . . . . . . . . . . . . . . 1956. Asymmetric encryption schemes . . . . . . . . . . . . . . . . . . . . . . . 2137. Digital signature schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2598. Digital identification schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 317A. Side-channel attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Part C. Performance evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3491. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3572. Theoretical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3613. Claimed Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

i

Draft

April

19, 2

004

4. Practical Software Implementation . . . . . . . . . . . . . . . . . . . . 3815. Hardware and Smartcard Implementations . . . . . . . . . . . . 389A. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399B. Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Part D. NESSIE selection for Phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

Part E. NESSIE portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Book III. The NESSIE portfolio

Part A. Definitions and notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4871. Mathematical objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4892. Data type conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4933. Key derivation functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

Part B. Block Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4991. MISTY1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5012. AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5193. Camellia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5274. SHACAL-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555

Part C. Collision-Resistant Hash Functions . . . . . . . . . . . . . . . . . . . . . . 5611. Whirlpool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5632. SHA-256, SHA-384 and SHA-512 . . . . . . . . . . . . . . . . . . . . . . 573

Part D. Message Authentication Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 5811. UMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5832. TTMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6053. EMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6174. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623

Part E. Asymmetric encryption schemes . . . . . . . . . . . . . . . . . . . . . . . . . 6311. PSEC-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6332. RSA-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6393. ACE-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645

Part F. Digital signature schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6551. RSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6572. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6653. SFLASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669

Part G. Asymmetric Identification Schemes . . . . . . . . . . . . . . . . . . . . . . 679

ii

Draft

April

19, 2

004

1. GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681

Book IV. Selected research papers

About the NESSIE submission “Using the general next bitpredictor like an evaluation criteria”by Markus Dichtl and Pascale Serf . . . . . . . . . . . . . . . . . . . . . . . 691

Constructive Methods for the Generation of Prime Numbersby Marc Joye and Pascal Paillier . . . . . . . . . . . . . . . . . . . . . . . . . 695

Cryptanalysis of LILI-128by Steve Babbage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707

Differential, Linear, Boomerang and Rectangle Cryptanalysisof Reduced-Round Camelliaby Taizo Shirai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

Efficient FPGA Implementations of Block Ciphers Khazadand MISTY1by François-Xavier Standaert, Gaël Rouvroy, Jean-Jacques

Quisquater and Jean-Didier Legat . . . . . . . . . . . . . . . . . . . . . . . . 731High Probability Linear Hulls in Q

by Liam Keliher, Henk Meijer and Stafford E. Tavares . . . . . 749Improved Analysis of the BMGL Keystream Generator

by Johan H̊astad and Mats Naslund . . . . . . . . . . . . . . . . . . . . . . 763Some modes of use of the GPS identification scheme

by Marc Girault, Guillaume Poupard and Jacques Stern . . . 777

Book V. References

iii

Draft

April

19, 2

004

Book I

An Introduction to theNESSIE Project

Draft

April

19, 2

004

Draft

April

19, 2

004

1. Introduction

Abstract. In February 2000 the NESSIE project has launched an opencall for the next generation of cryptographic algorithms. These algorithmsshould offer a higher security and/or confidence level than existing ones,and should be better suited for the constraints of future hardware andsoftware environments. The NESSIE project has received 39 algorithms,many of these from major players. In October 2001, the project com-pleted the first phase of the evaluation and has selected 24 algorithmsfor the second phase. The selection of the portfolio of 17 recommendedalgorithms has been announced in February 2003. This article presentsan introduction to the NESSIE project.

NESSIE (New European Schemes for Signature, Integrity, and Encryption) is aresearch project within the Information Societies Technology (IST) Programmeof the European Commission. The participants of the project are:

– Katholieke Universiteit Leuven (Belgium), coordinator;– Ecole Normale Supérieure (France);– Royal Holloway, University of London (U.K.);– Siemens Aktiengesellschaft (Germany);– Technion - Israel Institute of Technology (Israel);– Université Catholique de Louvain (Belgium); and– Universitetet i Bergen (Norway).

NESSIE is a 3-year project, which started on January 1, 2000. This paper presentsthe state of the project, and it is organized as follows. Section 2 discusses theNESSIE call and its results. Section 3 discusses the tools which the project isdeveloping to support the evaluation process. Sections 4 and 5 deal with the se-curity and performance evaluation respectively, and Sect. 6 discusses the selectionof algorithms for the 2nd phase. Section 7 raises some intellectual property issues.The NESSIE approach towards dissemination and standardization is presentedin Section 8. Finally, conclusions are put forward in Section 9.

Detailed and up to date information on the NESSIE project is available atthe project web site http://cryptonessie.org/.

† Bart PreneelKatholieke Univ. Leuven, Dept. Electrical Engineering-ESAT,Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, [email protected]

Draft

April

19, 2

004

4 Book I. An Introduction to the NESSIE Project

Draft

April

19, 2

004

2. NESSIE Call

In the first year of the project, an open call for the submission of cryptographicalgorithms, as well as for evaluation methodologies for these algorithms has beenlaunched. The scope of this call has been defined together with the project indus-try board (PIB) (cf. Sect. 8), and it was published in February 2000. The deadlinefor submissions was September 29, 2000. In response to this call NESSIE received40 submissions, all of which met the submission requirements.

2.1 Contents of the NESSIE Call

The NESSIE call includes a request for a broad set of algorithms providing dateconfidentiality, data authentication, and entity authentication. These algorithmsinclude block ciphers, stream ciphers, hash functions, MAC algorithms, digitalsignature schemes, and public-key encryption and identification schemes (for def-initions of these algorithms, see [441]). In addition, the NESSIE call asks forevaluation methodologies for these algorithms. While key establishment proto-cols are also very important, it was felt that they should be excluded from thecall, as the scope of the call is already rather broad.

The scope of the NESSIE call is much wider than that of the AES call launchedby NIST [630], which was restricted to 128-bit block ciphers. It is comparableto that of the RACE Project RIPE (Race Integrity Primitives Evaluation, 1988-1992) [116] (confidentiality algorithms were excluded from RIPE for political rea-sons) and that of the Japanese CRYPTREC project [631] (which also includeskey establishment protocols and pseudo-random number generation). Anotherdifference is that both AES and CRYPTREC intend to produce algorithms forgovernment standards. The results of NESSIE will not be adopted by any gov-ernment or by the European commission. However, the intention is that relevantstandardization bodies will adopt these results. As an example, algorithms for dig-ital signature and hash functions may be included in the EESSI standardizationdocuments which specify algorithms recommended for the European ElectronicSignature Directive.

The call also specifies the main selection criteria which will be used to eval-uate the proposals. These criteria are long-term security, market requirements,efficiency, and flexibility. Primitives can be targeted towards a specific environ-ment (such as 8-bit smart cards or high-end 64-bit processors), but it is clearlyan advantage to offer a wide flexibility of use. Security is put forward as the

Draft

April

19, 2

004


most important criterion, as security of a cryptographic algorithm is essential toachieve confidence and to build consensus.

For the security requirements of symmetric algorithms, two main securitylevels are specified, named normal and high. The minimal requirements for asymmetric algorithm to attain either the normal or high security level dependon the key length, internal memory, or output length of the algorithm. For blockciphers a third security level, normal-legacy , is specified, with a block size of 64bits compared to 128 bits for the normal and high security level. The motivationfor this request are applications such as UMTS/3GPP, which intend to use 64-bitblock ciphers for the next 10-15 years. For the asymmetric algorithms, a varyingsecurity level is accepted, with as minimum about 280 3-DES encryptions.

If selected by NESSIE, the algorithm should preferably be available royalty-free. If this is not possible, then access should be non-discriminatory. The submit-ter should state the position concerning intellectual property and should updateit when necessary.

The submission requirements are much less stringent than for AES, particu-larly in terms of the requirement for software implementations (only ‘portable C’is mandatory).

2.2 Response to the NESSIE Call

The cryptographic community has responded very enthusiastically to the call.Thirty nine algorithms have been received, as well as one proposal for a test-ing methodology. After an interaction process, which took about one month, allsubmissions comply with the requirements of the call. There are 26 symmetricalgorithms:

– seventeen block ciphers, which is probably not a surprise given the increasedattention to block cipher design and evaluation as a consequence of the AEScompetition organized by NIST. They are divided as follows:– six 64-bit block ciphers: CS-Cipher, Hierocrypt-L1, IDEA, Khazad,

MISTY1, and Nimbus;– seven 128-bit block ciphers: Anubis, Camellia, Grand Cru, Hierocrypt-3,

Noekeon, Q, and SC2000 (none of these seven come from the AES process);– one 160-bit block cipher: Shacal; and– three block ciphers with a variable block length: NUSH (64, 128, and 256

bits), RC6 (at least 128 bits), and SAFER++ (64 and 128 bits).– six synchronous stream ciphers: BMGL, Leviathan, LILI-128, SNOW,

SOBER-t16, and SOBER-t32.– two MAC algorithms: Two-Track-MAC and UMAC; and– one collision-resistant hash function: Whirlpool.

Thirteen asymmetric algorithms have been submitted:

– five asymmetric encryption schemes: ACE Encrypt, ECIES, EPOC, PSEC, andRSA-OAEP (both EPOC and PSEC have three variants);

Draft

April

19, 2

004

2. NESSIE Call — 2.2 Response to the NESSIE Call 7

– seven digital signature algorithms: ACE Sign, ECDSA, ESIGN, FLASH,QUARTZ, RSA-PSS, and SFLASH; and

– one identification scheme: GPS.

Approximately1 seventeen submissions originated within Europe (6 fromFrance, 4 from Belgium, 3 from Switzerland, 2 from Sweden), nine in North Amer-ica (7 USA, 2 from Canada), nine in Asia (8 from Japan), three in Australia andthree in South America (Brazil). The majority of submissions originated withinindustry (27); seven came from academia, and six are the result of a joint effortbetween industry and academia. Note however that the submitter of the algo-rithm may not be the inventor, hence the share of academic research is probablyunderestimated by these numbers.

On November 13–14, 2000 the first NESSIE workshop was organized in Leuven(Belgium), where most submissions were presented. All submissions are availableon the NESSIE web site [633].

1 Fractional numbers have been used to take into account algorithms with submittersover several continents/countries – the totals here are approximations by integers,hence they do not add up to 40.

Draft

April

19, 2

004


Draft

April

19, 2

004

3. Tools

It is clear that modern computers and sophisticated software tools cannot replacehuman cryptanalysis. Nevertheless, software tools can play an important role inmodern cryptanalysis. In most cases, the attacks found by the cryptanalyst re-quire a large number of computational steps, hence the actual computation ofthe attack is performed on a computer. However, software and software tools canalso be essential to find a successful way to attack a symmetric cryptographic al-gorithm; examples include differential and linear cryptanalysis, dependence tests,and statistical tests.

Within NESSIE, we distinguish two classes of tools. The general tools arenot specific for the algorithms to be analyzed. Special tools, which are specificfor the analysis of one algorithm, are implemented when, in the course of thecryptanalysis of an algorithm, the need for such a tool turns up.

For the evaluation of the symmetric submissions, a comprehensive set of gen-eral tools is available within the project. These tools are in part based on animproved version of the tools developed by the RIPE (RACE Integrity PrimitivesEvaluation) project [116]. These test include: the frequency test, the collision test,the overlapping m-tuple test, the gap test, the constant runs test, the coupon col-lector’s test, Maurer’s universal test [429], the poker test, the spectral test, thecorrelation test, the rank test, the linear, non-linear, and dyadic complexity test,the Ziv-Lempel complexity test, the dependence test, the percolation test, thelinear equation, linear approximation and correlation immunity test, the linearfactors test, and a cycle detection tool.

The NESSIE project is also developing a new generic tool to analyze blockciphers with differential [78] and linear cryptanalysis [422]. This tool is based ona general description language for block ciphers.

In September 2000, the US NIST published a suite of statistical tests for theevaluation of sequences of random or pseudo-random bits; this document has beenrevised in December 2000 [469]. A careful comparison has been made betweenthe RIPE and NIST test suites.

The software for these tools will not be made available outside the project,but all the results obtained using these tools will be made public in full detail.

Draft

April

19, 2

004


Draft

April

19, 2

004

4. Security Evaluation

We first describe the internal process within NESSIE used to assess submissions.Initially each submission was assigned to a NESSIE partner, who performed ba-sic checks on the submission, such as compliance with the call, working software,obvious weaknesses etc. The aim of this initial check was mainly to ensure thatsubmissions were specified in a consistent and cogent form in time for the Novem-ber 2000 workshop. It is vital for proper security assessments that the algorithmsare fully and unambiguously described. This process required interaction withsome submitters to ensure that the submissions were in the required form.

The next internal stage (November 2000) was to assign each submission to apair of NESSIE partners for an initial detailed evaluation. Each submission hasthen been subject to two independent initial assessments. After the two initialassessments of a submission have taken place, the two NESSIE partners have pro-duced a joint summary of their assessments concerning that submission. Basedon this initial evaluation, algorithms were dismissed or subjected to further ded-icated analysis.

Next, an open workshop was organized in Egham (UK) on September 12-13,2001 to discuss the security and performance analysis of the submissions. Thepresenters include both researchers from the NESSIE project, but also submitters,members from the NESSIE PIB, and members from the cryptographic communityat large.

Following this workshop, a comprehensive security evaluation report has beenpublished [478]. The document gives an overview of generic attacks on the dif-ferent type of algorithms. Moreover, for each symmetric algorithm it presents ashort description, the security claims by the designers, and the reported weak-nesses and attacks. The part on asymmetric algorithms contains a discussion ofsecurity assumptions, security models, and of the methodology to evaluate thesecurity. For each algorithm, a short description is followed by a discussion of theprovable security (which security properties are proved under which assumptions)and of the concrete security reduction.

Draft

April

19, 2

004


Draft

April

19, 2

004

5. Performance Evaluation

Performance evaluation is an essential part in the assessment of a cryptographicalgorithm: efficiency is a very important criterion in deciding for the adoption ofan algorithm.

The candidates will be used on several platforms (PCs, smart cards, dedicatedhardware) and for various applications. Some applications have tight timing con-straints (e.g., payment applications, cellular phones); for other applications a highthroughput is essential (e.g., high speed networking, hard disk encryption).

First a framework has been defined to compare the performance of algorithmson a fair and equal basis. It will be used for all evaluations of submitted candi-dates. First of all a theoretical approach has been established. Each algorithm isdissected into three parts: setup (independent of key and data), precomputations(independent of data, e.g., key schedule) and the algorithm itself (that must berepeated for every use). Next a set of four test platforms has been defined onwhich each candidate may be tested. These platforms are smart cards, 32-bitPCs, 64-bit machines, and Field Programmable Gate Arrays (FPGAs).

Then rules have been defined which specify how performance should be mea-sured on these platforms. The implementation parameters depend on the plat-form, but may include RAM, speed, code size, chip area, and power consumption.On smart cards, only the following parameters will be taken into account, in de-creasing order of importance: RAM usage, speed, code size. On PCs, RAM hasvery little impact, and speed is the main concern. On FPGAs, throughput, la-tency, chip area and power consumption will be considered. Unfortunately, thelimited resources of the project will not allow for the evaluation of dedicatedhardware implementations (ASICs), but it may well be that teams outside theproject can offer assistance for certain algorithms.

The project will also consider the resistance of implementations to physicalattacks such as timing attacks [374], fault analysis [79, 104], and power analysis[375]. For non constant-time algorithms (data or key dependence, asymmetrybetween encryption and decryption) the data or key dependence will be analyzed;other elements that will be taken into account include the difference betweenencryption and decryption, and between signature and verification operation.For symmetric algorithms, the key agility will also be considered.

This approach will result in the definition of a platform dependent test andin several platform dependent rekeying scenarios. Low-cost smart cards will onlybe used for block ciphers, MACs, hash functions, stream ciphers, pseudo-randomnumber generation, and identification schemes.

Draft

April

19, 2

004


In order to present performance information in a consistent way within theNESSIE project, a performance ‘template’ has been developed. The goal of thistemplate is to collect intrinsic information related to the performance of thesubmitted candidates. A first part describes parameters such as word size, mem-ory requirement, key size and code size. Next the basic operations are analyzed,such as shift/rotations, table look-ups, permutations, multiplications, additions,modular reduction, exponentiation, inversion,. . . . Then the nature and speedof precomputations (setup, key schedule, etc.) are described. Elements such asthe dependence on the keys and on the inputs determine whether the code isconstant-time or not. Alternative representations of the algorithms are exploredwhen feasible.

The result of the preliminary performance evaluation are presented in [477].This document contains an overview of the performance claimed by the designers,a theoretical evaluation, and performance measurements of optimized C-code ona PC and a workstation. However, due to limited resources and the large numberof algorithms, it was not possible to guarantee full optimization for all algorithms.Nevertheless, it was felt that these results provide sufficient information to makea selection of algorithms for the 2nd phase of the project.

Draft

April

19, 2

004

6. Selection for the 2nd Phase

On September 24, 2001, the NESSIE project has announced the selection of can-didates for the 2nd phase of the project. Central to the decision process has beenthe project goal, that is, to come up with a portfolio of strong cryptographicalgorithms. Moreover, there was also a consensus that every algorithm in thisportfolio should have a unique competitive advantage that is relevant to an ap-plication.

It is thus clear that an algorithm could not be selected if it failed to meet thesecurity level required in the call. A second element could be that the algorithmfailed to meet a security claim made by the designer. A third reason to elimi-nate an algorithm could be that a similar algorithm exists with better security(for comparable performance) or with significantly better performance (for com-parable security). In retrospect, very few algorithms were eliminated because ofperformance reasons. It should also be noted that the selection was more compet-itive in the area of block ciphers, where many strong contenders were considered.The motivation for the decisions is given in [476].

Designers of submitted algorithms were allowed to make small alterationsto their algorithms; the main criterion to accept these alterations is that theyshould improve the algorithm and not substantially invalidate the existing secu-rity analysis. More information on the alterations can be found on the NESSIEwebpages [633].

The selected algorithms are listed below; altered algorithms are indicated witha ∗. Block ciphers:

– IDEA: MediaCrypt AG, Switzerland;– Khazad∗: Scopus Tecnologia S.A., Brazil and K.U.Leuven, Belgium;– MISTY1: Mitsubishi Electric Corp., Japan;– SAFER++64, SAFE++128: Cylink Corp., USA, ETH Zurich, Switzerland,

National Academy of Sciences, Armenia;– Camellia: Nippon Telegraph and Telephone Corp., Japan and Mitsubishi Elec-

tric, Japan;– RC6: RSA Laboratories Europe, Sweden and RSA Laboratories, USA;– Shacal: Gemplus, France.

Here IDEA, Khazad, MISTY1 and SAFER++64 are 64-bit block ciphers. Camel-lia, SAFER++128 and RC6 are 128-bit block ciphers, which will be compared toAES/Rijndael [181,470]. Shacal is a 160-bit block cipher based on SHA-1 [465]. A256-bit version of Shacal based on SHA-256 [472] has also been introduced in the

Draft

April

19, 2

004


second phase; this algorithm will be compared to an RC-6 and a Rijndael [181]variant with a block length of 256 bits (note that this variant is not included inthe AES standard). The motivation for this choice is that certain applications(such as the stream cipher BMGL and certain hash functions) can benefit froma secure 256-bit block cipher.Synchronous stream ciphers:

– SOBER-t16, SOBER-t32: Qualcomm International, Australia;– SNOW∗: Lund Univ., Sweden;– BMGL∗: Royal Institute of Technology, Stockholm and Ericsson Research, Swe-

den.

MAC algorithms and hash functions:

– Two-Track-MAC: K.U.Leuven, Belgium and debis AG, Germany;– UMAC: Intel Corp., USA, Univ. of Nevada at Reno, USA, IBM Research Lab-

oratory, USA, Technion, Israel, and Univ. of California at Davis, USA;– Whirlpool∗: Scopus Tecnologia S.A., Brazil and K.U.Leuven, Belgium.

The hash function Whirlpool will be compared to the new FIPS proposals SHA-256, SHA-384 and SHA-512 [472].Public-key encryption algorithms:

– ACE-KEM∗: IBM Zurich Research Laboratory, Switzerland (derived from ACEEncrypt);

– EPOC-2∗: Nippon Telegraph and Telephone Corp., Japan;– PSEC-KEM∗: Nippon Telegraph and Telephone Corp., Japan (derived from

PSEC-2);– ECIES∗: Certicom Corp., USA and Certicom Corp., Canada– RSA-OAEP∗: RSA Laboratories Europe, Sweden and RSA Laboratories, USA.

Digital signature algorithms:

– ECDSA: Certicom Corp., USA and Certicom Corp., Canada;– ESIGN∗: Nippon Telegraph and Telephone Corp., Japan;– RSA-PSS: RSA Laboratories Europe, Sweden and RSA Laboratories, USA;– SFLASH∗: BULL CP8, France;– QUARTZ∗: BULL CP8, France.

Identification scheme:

– GPS∗: Ecole Normale Supérieure, Paris, BULL CP8, France Télécom and LaPoste, France.

Many of the asymmetric algorithms have been updated at the beginning ofphase 2. For the asymmetric encryption schemes, these changes were driven inpart by the recent cryptanalytic developments, which occurred after the NESSIEsubmission deadline [243, 414, 583]. A second reason for these changes is theprogress of standardization within ISO/IEC JTC1/SC27 [584]. The standardsseem to evolve towards defining a hybrid encryption scheme, consisting of twocomponents: a KEM (Key Encapsulation Mechanism), where the asymmetric

Draft

April

19, 2

004

6. Selection for the 2nd Phase 17

encryption is used to encrypt a symmetric key, and a DEM (Data Encapsula-tion Mechanism), which protects both secrecy and integrity of the bulk datawith symmetric techniques (a “digital envelope”). This approach is slightly morecomplicated for encryption of a short plaintext, but it offers a more general solu-tion with clear advantages. Three of the five NESSIE algorithms (ACE Encrypt,ECIES and PSEC-2) have been modified to take into account this development.At the same time some other improvements have been introduced; as an example,ACE-KEM can be based on any abstract group, which was not the case for theoriginal submission ACE Encrypt. Other submitters decided not to alter theirsubmissions at this stage. For further details, the reader is referred to the exten-sive ISO/IEC draft document authored by V. Shoup [584]. The NESSIE projectwill closely monitor these developments. Depending on the progress, variants suchas RSA-KEM defined in [584] may be studied by the NESSIE project.

For the digital signature schemes, three out of five schemes (ESIGN, QUARTZand SFLASH) have been altered. In this case, there are particular reasons foreach algorithm (correction for the security proof to apply, improve performance,or preclude a new attack). The other two have not been modified. It should alsobe noted that PSS-R, which offers very small storage overhead for the signature,has not been submitted to NESSIE.

Draft

April

19, 2

004


Draft

April

19, 2

004

7. Intellectual Property

An important element in the evaluation is the intellectual property status. Whileit would be ideal for users of the NESSIE results that all algorithms recommendedby NESSIE were in the public domain, it is clear that this is for the time being notrealistic. The users in the NESSIE PIB have clearly stated that they prefer to seeroyalty-free algorithms, preferably combined with open source implementations.However, providers of intellectual property typically have different views.

One observation is that in the past, there has always been a very large differ-ence between symmetric and asymmetric cryptographic algorithms. Therefore itis not so surprising that NIST was able to require that the designers of the blockcipher selected for the AES would give away all their rights, if their algorithmwas selected; it is clear that this is not a realistic expectation for the NESSIEproject.

In this section we will attempt to summarize the intellectual property state-ments of the submissions retained for the 2nd phase. Note however that thisinterpretation is only indicative; for the final answer the reader is referred tothe intellectual property statement on the NESSIE web page [633], and to thesubmitters themselves.

Twelve out of 24 algorithms are in the public domain, or the submittersindicate that a royalty-free license will be given. These are the block ciphersKhazad, Misty1, Shacal, Safer++, the stream ciphers BMGL, SNOW, Sober-t16 and Sober-t32, the MAC algorithms Two-Track-MAC and UMAC, the hashfunction Whirlpool, and the public-key algorithms RSA-OAEP2 (public-key en-cryption) and RSA-PSS1 (digital signature scheme).

Royalty-free licenses will be given for the block cipher Camellia, for the public-key encryption algorithms EPOC-2 and PSEC-KEM, and for the digital signaturescheme ESIGN, provided that other companies with IPR to the NESSIE portfolioreciprocate.

The block cipher IDEA is free for non-commercial use only; for commercialapplications a license is required.

Licenses under reasonable and non-discriminatory terms will be given forACE-KEM (the detailed license conditions are rather complex). Additions tothe ‘reasonable and non-discriminatory’ terms are required for the public-key al-gorithms ECDSA and ECIES; it is required that the license holder reciprocatessome of his rights.

1 This statement does not hold for the variants of RSA with more than two primes.

Draft

April

19, 2

004


For the digital signature schemes SFLASH and QUARTZ the licensing con-ditions are expected to be non-discriminatory, but no decision has been madeyet. A similar statement holds for the identification scheme GPS, but in this casecertain applications in France may be excluded from the license.

Finally, the submitters of RC6 are willing to negotiate licenses on reasonableterms and conditions.

It is clear that intellectual property is always a complex issue, and it will notbe possible to resolve this completely within the framework of NESSIE. However,IPR issues may play an important role in the final selection process.

Draft

April

19, 2

004

8. Dissemination and Standardization

8.1 An Open Evaluation Process

The NESSIE project intends to be an open project, which implies that the mem-bers of the public are invited to contribute to the evaluation process. In order tofacilitate this process, all submissions are available on the NESSIE website, andcomments are distributed through this website. In addition, three open work-shops are organized during the project: the first two workshops have taken placein November 2000 and September 2001; the third one has been scheduled forNovember 2002.

8.2 The Project Industry Board

The Project Industry Board (PIB) was established to ensure that the projectaddresses real needs and requirements of industry dealing with the provision anduse of cryptographic techniques and cryptographic products. The goals for theBoard may be summarized as follows:

– contribute to dissemination: outwards through a member’s contacts with indus-try and users, and also through passing NESSIE information into the member’sown organization influencing products and directions;

– collaboration with the Project in formulation of the call and its goals andrequirements;

– contribution to consensus building through influence and contacts in the in-dustry and marketplace;

– identification of industry requirements from market needs and corporate strate-gies;

– guidance and judgment on the acceptability and relevance of submissions andevaluation results;

– support in standardization of NESSIE results;– contribution to Project workshops;– practical contributions to analysis and evaluation of submissions;– identification of gaps in the scope of the submissions;– ongoing guidance during the evaluation of the processes and validity of results.

Two meetings are held per year, but the PIB may request additional meetingsto address specific issues or concerns that may arise. Membership was originally

Draft

April

19, 2

004


by invitation, but subsequently a number of additional companies have requestedand obtained membership. Currently the PIB consists of about twenty leadingcompanies which are users or suppliers of cryptology.

8.3 Standardization

Together with the NESSIE PIB, the project will establish a standardization strat-egy. It is not our intention to establish a new standardization body or mech-anism, but to channel the NESSIE results to the appropriate standardizationbodies, such as, ISO/IEC, IETF, IEEE and EESSI. We believe that the NESSIEapproach of open evaluation is complementary to the approach taken by stan-dardization bodies. Indeed, these bodies typically do not have the resources toperform any substantial security evaluation, which may be one of the reasonswhy standardization in security progresses often more slowly than anticipated.

The NESSIE project will also take into account existing and emerging stan-dards, even if these have not been formally submitted to the NESSIE project.Two recent examples in this context come from the standardization efforts run byNIST: AES/Rijndael [181,470] will be used as a benchmark for the other 128-bitblock ciphers, and the NESSIE project will study the security and performanceof the new SHA variants with results between 256 and 512 bits [472].

Draft

April

19, 2

004

9. Conclusion

We believe that after two years, the NESSIE project has made important stepstowards achieving its goals. This can be deduced from the high quality submis-sions received from key players in the community, and by the active participationto the workshops.

The first two years of the NESSIE project have also shown that initiativesof this type (such as AES, RIPE, CRYPTREC) can bring a clear benefit tothe cryptographic research community and to the users and implementors ofcryptographic algorithms. By asking cryptographers to design concrete and fullyspecified schemes, they are forced to make choices, to think about real life opti-mizations, and to consider all the practical implications of their research. Whileleaving many options and variants in a construction may be very desirable in aresearch paper, it is often confusing for a practitioner. Implementors and userscan clearly benefit from the availability of a set of well defined algorithms, thatare described in a standardized way.

The developments in the last years have also shown that this approach canresult in a better understanding of the security of cryptographic algorithms. Wehave also learned that concrete security proofs are an essential tool to buildconfidence, particularly for public key cryptography (where constructions can bereduced to mathematical problems believed to be hard) and for constructionsthat reduce the security of a scheme to other cryptographic algorithms. At thesame time, we have learned that it is essential to study proofs for their correctnessand to evaluate the efficiency of such reductions.

Acknowledgments

I would like to thank all the members of and the contributors to the NESSIEproject. The work described in this paper has been supported by the Commissionof the European Communities through the IST Programme under Contract IST–1999–12324.Bart Preneel, NESSIE coordinator

Draft

April

19, 2

004


Draft

April

19, 2

004

Book II

Evaluation

Draft

April

19, 2

004

Draft

April

19, 2

004

Part A

Submitted primitives

Draft

April

19, 2

004

Draft

April

19, 2

004

1. Call for Cryptographic Primitives

Version 2.2, 8th March 2000

Introduction

NESSIE (New European Schemes for Signature, Integrity, and Encryption) isa project within the Information Societies Technology (IST) Programme of theEuropean Commission. The participants of the project are

Participant name CountryKatholieke Universiteit Leuven BelgiumÉcole Normale Supérieure FranceFondazione Ugo Bordoni ItalyRoyal Holloway, University of London U.K.Siemens Aktiengesellschaft GermanyTechnion - Israel Institute of Technology IsraelUniversité Catholique de Louvain BelgiumUniversitetet i Bergen Norway

NESSIE is a 3-year project, which started on 1st January 2000. Further in-formation about NESSIE is available at http://cryptonessie.org.

The main objective of the project is to put forward a portfolio of strongcryptographic primitives for a number of different platforms. These primitiveswill be obtained after an open call and evaluated using a transparent and openprocess. They should be the building blocks of the future standard protocols forthe information society.

The deadline for the submission of primitives will be 29th Septem-ber 2000. A workshop will be organised for submitters to present their primitiveson 13-14 November 2000 in Leuven, Belgium.

Background

In the information society, cryptology has become a key enabling technology toprovide secure electronic commerce and electronic business, secure communica-

This call was widely dissemniated and published on the NESSIE web site http://www.cosic.esat.kuleuven.ac.be/nessie/call/.

Draft

April

19, 2

004

30 Book II. Evaluation — Part A. Submitted primitives

tions, secure payments, and the protection of the privacy of the citizen. Cryp-tology is a field that evolves quickly, and society needs robust primitives thatprovide long term security (15 to 20 years or more), rather than ad hoc solu-tions that need to be frequently replaced. With the current state of the art incryptology, it is not possible to have provably secure solutions, although there isa trend to prove more and more security properties of primitives. However, foruse in real applications, sufficient confidence in a primitive can only be achievedwhen primitives have been subjected to an open and independent evaluation fora sufficient amount of time.

The procedure of an open call followed by an evaluation process has beenpreviously used in the selection process for the DES, the RIPE project, and theAES. The scope of this call for primitives is wider than the NIST call for AES. Theinformation society needs other cryptographic primitives than just block ciphers.Thus the NESSIE call seeks cryptographic primitives in many areas, such as:

– Stream ciphers: for applications with high throughput requirements or tightperformance constraints etc.

– MACs: for high-speed authentication of packets etc.– Families of Pseudo-random functions: for key derivation, entity authentication

and encryption etc.– Digital signatures and hash functions: for electronic commerce, business and

payment etc.– Asymmetric encryption schemes.– Asymmetric identification schemes.

Furthermore, there is a wide range of environments in which cryptographic prim-itives are used. Thus the NESSIE project will consider primitives designed for usein specific environments (though flexibility is clearly desirable). The NESSIE callalso asks for testing methodologies of these primitives (such as statistical tests).

The results of this call will then be subjected to a thorough and open evalua-tion process. In addition to the responses to the call, the project will also considera selection from existing standards containing such primitives. The main selectioncriteria will be long-term security, market requirements, efficiency (performance),and flexibility.

It is also a goal of the project to disseminate widely the results of the project,and to build a consensus based on these results. In order to achieve this, an In-dustry Group has been established. The Industry Group consists of about twentyleading European companies in this area and will be consulted on a regular basisthroughout the project. It is expected that the Industry Group will provide inputconcerning the nature of the final call (requirements and definitions for primi-tives), the relevance of the selection criteria, and the standardisation strategy. Animportant part of the dissemination will be the introduction of these primitivesinto standardisation bodies (ISO, ISO/IEC, CEN, IEEE, IETF), based in parton the consensus achieved within the project. It is anticipated that the results ofthe project will also be published in scientific publications.

Draft

April

19, 2

004

1. Call for Cryptographic Primitives 31

General Requirements

This section discusses the general selection criteria, the type of primitives re-quired, and the security requirements for each primitive.

Selection Criteria

The main selection criteria will be long-term security, market requirements, effi-ciency (performance) and flexibility.

– Security is the most important criterion, because security of a cryptographicprimitive is essential to achieve confidence and to build consensus. It is antici-pated that this evaluation process will be influenced by developments outsidethe project (such as new attacks or analysis techniques).

– A second criterion relates to market requirements. Market requirements arerelated to the need for a primitive, its usability, and the possibility for world-wide use.

– A third criterion is the performance of the primitive in the specified environ-ment. For software, the range of environments considered include 8-bit proces-sors (as found in inexpensive smart cards), 32-bit processors (e.g., the Pentiumfamily) to the modern 64-bit processors. For hardware, both FPGAs and ASICswill be considered.

– A fourth criterion is the flexibility of the primitive. It is clearly desirable for aprimitive to be suitable for use in a wide-range of environments.

Type of Primitives

The NESSIE project is seeking submissions of strong cryptographic primitivesin the categories given below. The NESSIE project is particularly interested inreceiving submissions in categories that have not received much standardisationeffort.

1. Block ciphers2. Synchronous stream ciphers3. Self-synchronising stream ciphers4. Message Authentication Codes (MACs)5. Collision-resistant hash functions6. One-way hash functions7. Families of pseudo-random functions8. Asymmetric encryption schemes9. Asymmetric digital signature schemes

10. Asymmetric identification schemes

Definitions are broadly as given in the Handbook of Applied Cryptography (ISBN:0-8493-8523-7).

Draft

April

19, 2

004


Security Requirements for Each Primitive

Symmetric Primitives (Primitives 1-7)

There are two main security levels for symmetric primitives. These are namednormal and high. For block ciphers, normal-legacy is also provided. The minimalrequirements for a symmetric primitive to attain a security level are given below.

1. Block ciphers.a) High. Key length of at least 256 bits. Block length at least 128 bitsb) Normal. Key length of at least 128 bits. Block length at least 128 bits.c) Normal-Legacy. Key length of at least 128 bits. Block length 64 bits

2. Synchronous stream ciphers.a) High. Key length of at least 256 bits. Internal memory of at least 256

bits.b) Normal. Key length of at least 128 bits. Internal memory of at least 128

bits.3. Self-synchronising stream ciphers.

a) High. Key length of at least 256 bits. Internal memory of at least 256bits.

b) Normal. Key length of at least 128 bits. Internal memory of at least 128bits.

4. Message Authentication Codes (MACs). The primitive should supportall output lengths (in multiples of 32 bits) up to the key length (inclusive).a) High. Key length of at least 256 bits.b) Normal. Key length of at least 128 bits.

5. Collision-Resistant Hash functions.a) High. Output length of at least 512 bits.b) Normal. Output length of at least 256 bits.

6. One-Way Hash functions. These hash functions shall be preimage resis-tant and second preimage resistant.a) High. Output length of at least 256 bits.b) Normal. Output length of at least 128 bits.

7. Families of Pseudo-random functions. Fixed block length of at least 128bits.a) High. Key length of at least 256 bits.b) Normal. Key length of at least 128 bits.

Asymmetric Primitives (Primitives 8-10)

The security parameters should be chosen such that the most efficient attackon the primitive requires a computational effort of the order of 280 3-DES en-cryptions. Furthermore, a table giving the security levels in terms of the securityparameters should be provided.

8. Asymmetric encryption schemes (deterministic or randomised).The minimal computational effort for an attack should be of the order of280 3-DES encryptions.

Draft

April

19, 2

004


9. Asymmetric digital signature schemes. The minimal computational ef-fort for an attack should be of the order of 280 3-DES encryptions.

10. Asymmetric identification schemes. The minimal computational effortfor an attack should be of the order of 280 3-DES encryptions. The probabilityof impersonation should be smaller than 2−32.

Evaluation of Proposals

Detailed Evaluation Criteria

Security Criteria

– An attack should be at least as difficult as the generic attacks against the typeof primitive (exhaustive search, birthday attack etc.).

– Primitives will be evaluated against the security claims of the submitter. An at-tack requiring lower computing resources than claimed would usually disqualifythe submission.

– Primitives will be evaluated within the stated environment. Thus, considerationof vulnerability to side channel attacks (e.g., timing attacks, power analysis)may be appropriate.

Implementation Criteria

– Software and hardware efficiency will be compared with similar submissionsand existing primitives.

– Execution code and memory sizes will be assessed according to their relevancein different contexts. Special attention will be paid to smart cards.

– Submitted primitives will be assessed against claimed performance, though itis clearly preferable for primitives to offer wide flexibility of use.

Other Criteria

– Simplicity and clarity of design are important considerations. Variable param-eter sizes are less important.

Licensing Requirements

– Submitted primitives should, if selected by NESSIE, be available royalty-free.If this is not possible, then access is non-discriminatory.

– The submitter should state the position concerning intellectual property. Thisstatement should be updated when necessary.

The Evaluation Process

The NESSIE project reserves the right to reject submitted primitives that arenot clearly specified and easily comprehensible or that fail to meet the NESSIErequirements in some way.

The NESSIE evaluation process is an open process. Thus as part of the eval-uation process, the NESSIE project welcomes comments about both submitted

Draft

April

19, 2

004


primitives and the evaluation process, including evaluation methodologies. To fa-cilitate this process, three NESSIE workshops will be organised; the first will beon 13-14 November 2000, shortly after the deadline for submission of primitives.As part of the evaluation process, the NESSIE partners will give security and per-formance assessments of the submitted primitives. At the end of the evaluationprocess, the NESSIE project may recommend certain submissions for standardi-sation. The NESSIE project is to have two phases. A timetable for the NESSIEproject is given below.

2000 January Beginning of first phase of NESSIE2000 January Creation of Industry Board2000 March Call for Cryptographic Primitives2000 September Submission deadline2000 November First NESSIE workshop2001 June Preliminary assessment of submissions2001 June End of first phase of NESSIE

2001 July Beginning of second phase of NESSIE2001 September Second NESSIE workshop2002 February Preliminary selection of submissions2002 February Standardisation Plan2002 October Third NESSIE workshop2002 December Final selection of submissions2002 December Final report of NESSIE project2002 December End of second phase of NESSIE

Formal Submission Requirements

The following are to be provided with any submission:

A. Cover sheet with the following information1. Name of submitted algorithm2. Type of submitted algorithm, proposed security level, and proposed environ-

ment.3. Principal submitter’s name, telephone, fax, organization, postal address, e-

mail address4. Name(s) of auxiliary submitter(s)5. Name of algorithm inventor(s)/developer(s)6. Name of owner, if any, of the algorithm (normally expected to be the same

as the submitter)7. Signature of submitter8. (optional) Backup point of contact (telephone, fax, postal address, e-mail)

B. Primitive specification and supporting documentation1. A complete and unambiguous description of the primitive in the most suit-

able forms, such as a mathematical description, a textual description withdiagrams, or pseudo-code. The specification of a primitive using code is not

Draft

April

19, 2

004


permitted. Input and output should be in the form of binary strings. Forasymmetric algorithms, a method for key generation and parameter selec-tion needs to be specified.

2. A statement that there are no hidden weaknesses inserted by the designers.3. A statement of the claimed security properties and expected security level,

together with an analysis of the primitive with respect to standard cryptan-alytic attacks. Weak keys should also be considered.

4. A statement giving the strengths and advantages of the primitive.5. A design rationale explaining design choices.6. A statement of the estimated computational efficiency in software. Estimates

are required for different sub-operations like key setup, primitive setup, andencryption/decryption (as far as applicable). The efficiency should be esti-mated both in cycles per byte and cycles per block, indicating the processortype and memory. If performance varies with the size of the inputs, then val-ues for some typical sizes should be provided. Optionally the designers mayprovide estimates for performance in hardware (area, speed, gate count, adescription in VHDL).

7. A description of the basic techniques for implementers to avoid implemen-tation weaknesses.

C. Implementations and test values1. A reference implementation, in portable C. For symmetric primitives, NESSIE

has specified an API, published on the NESSIE web site. For asymmetricprimitives, it is allowed to use a ‘standard’ library for mathematical func-tions, such as multi-precision arithmetic (e.g., Lydia). See here for moreinformation.

2. A sufficient number of test vectors. The NESSIE project will supply softwareto generate test vectors for symmetric primitives.

3. Optionally, an optimized implementation for some architectures, a JAVAimplementation, an assembly language implementation.

D. Intellectual property statement– A statement that gives the position concerning intellectual property position

and the royalty policy for the primitive (if selected). This statement shouldinclude an undertaking to update the NESSIE project when necessary.

Requirements:

– Items A, B, and D shall be supplied in paper form and in electronic form(Adobe PDF or PostScript on one or more diskettes).

– Item C shall be supplied in electronic form only (diskette).– Item A, B, C and D shall be supplied on separate 3,5”1.44 MB floppy diskettes,

formatted for use on an IBM-compatible PC. Every diskette shall be labeledwith the submitter’s name, the name of the primitive, the number, and thedate. Every diskette shall contain an ASCII file labeled ”README”, that listsall files included on the diskette and provides a brief description of the contentof each file.

– All submissions must be in English.– Classified and/or proprietary submissions shall not be considered.

Draft

April

19, 2

004


– Paper submissions and diskettes shall be sent to the following address:

Prof. Bart PreneelNESSIE Project CoordinatorKatholieke Universiteit LeuvenDept. Electrical Engineering-ESAT/COSICKard. Mercierlaan 94,B-3001 HeverleeBELGIUM

They should arrive on or before 29th September 2000.– Optionally, an electronic version may be sent to [email protected].

An acknowledgment will be sent by email and by regular mail within 5 workingdays.

General questions for clarification of the formal submission requirements andof the evaluation criteria can be sent to [email protected]. Answers toquestions that are relevant to other submissions will be made available at http://www.cryptonessie.org/. The NESSIE project will endeavour to answer allrelevant questions in a timely manner.

Call for Evaluation Criteria

In addition to the criteria given above, the NESSIE project also invites sug-gestions for Evaluation Criteria, such as testing methodologies (eg. statisticaltesting).

Further Information

Email: [email protected]: http://www.cryptonessie.org/.

Draft

April

19, 2

004

2. The submissions

Block ciphers

– Anubis. [37]Submitted by Paulo S.L.M. Barreto and Vincent Rijmen.

– Camellia. [24]Submitted by Kazumaro Aoki, Tetsuya Ichikawa, Masayuki Kanda, MitsuruMatsui, Shiho Moriai, Junko Nakajima and Toshio Tokita, on behalf of NTTCorp.

– CS-cipher. [234]Submitted by Pierre-Alain Fouque, Jacques Stern and Serge Vaudenay, onbehalf of CS Communication & Systèmes.

– Grand Cru. [112]Submitted by Johan Borst.

– Hierocrypt. [493] – Hierocrypt-L1 and Hierocrypt-3.Submitted by Kenji Ohkuma, Fumihiko Sano, Hirofumi Muratani, MasahikoMotoyama and Shinichi Kawamura, on behalf of Toshiba Corp.

– IDEA. [387]Submitted by Richard Straub, on behalf of MediaCrypt AG.

– Khazad. [39]Submitted by Paulo S.L.M. Barreto and Vincent Rijmen.

– MISTY1. [426]Submitted by Eisaku Takeda, on behalf of Mitsubishi.

– Nimbus. [410]Submitted by Alexis W. Machado.

– Noekeon. [180]Submitted by Joan Daemen, Michael Peeters, Gilles van Assche and VincentRijmen.

– NUSH. [391]Submitted by Anatoly N. Lebedev and Alexey A. Volchkov, on behalf of LANCrypto, Int.

– Q. [434]Submitted by Leslie McBride, on behalf of Mack One Software.

– RC6. [324]Submitted by Jakob Jonsson and Burton S. Kaliski, Jr, on behalf of RSA.

Draft

April

19, 2

004


– SAFER++. [420]Submitted by James L. Massey, Gurgen Khachatrian and Melsik K. Kuregian,on behalf of Cylink Corp.

– SC2000. [569]Submitted by Takeshi Shimoyama, Hitoshi Yanami, Kazuhiro Yokoyama,Masahiko Takenaka, Kouichi Itoh, Jun Yajima, Naoya Torii and HidemaTanaka, on behalf of Fujitsu Laboratories LTD.

– SHACAL. [281] – SHACAL-1 and SHACAL-2.Submitted by Helena Handschuh and David Naccache, on behalf of Gemplus.

Stream ciphers and pseudo-random number generators

– BMGL. [285]Submitted by Johan H̊astad and Mats Nāslund.

– SNOW. [214]Submitted by Patrick Ekdahl and Thomas Johansson.

– SOBER. [289] – SOBER-t16 and SOBER-t32.Submitted by Philip Hawkes and Gregory G. Rose, on behalf of QualcommInternational.

– LEVIATHAN. [435]Submitted by David McGrew and Scott R. Fluhrer, on behalf of Cisco Systems,Inc.

– LILI-128. [187]Submitted by Ed Dawson, William Millan, Lyta Penna, Leone Simpson andJovan Dj. Golic.

Hash functions

– Whirlpool. [38]Submitted by Paulo S.L.M. Barreto and Vincent Rijmen.

Message authentication codes

– UMAC. [379]Submitted by Ted Krovetz, John Black, Shai Halevi, Alejandro Hevia, HugoKrawczyk and Phillip Rogaway.

– Two-Track-MAC. [609]Submitted by Bart Van Rompay and Bert Den Boer.

Asymmetric encryption schemes

– ACE-KEM. [563] – Upgrade of ACE-Encrypt.Submitted by Thomas Schweinberger and Victor Shoup, on behalf of IBM.

Draft

April

19, 2

004

2. The submissions 39

– EPOC. [239] – EPOC-1, EPOC-2 and EPOC-3.Submitted by Eiichiro Fujisaki, Tetsutaro Kobayashi, Hikaru Morita, HiroakiOguro, Tatsuaki Okamoto, Satomi Okazaki, David Pointcheval and ShigenoriUchiyama, on behalf of NTT Corp.

– ECIES. [320]Submitted by Don B. Johnson and Simon Blake-Wilson, on behalf of Certicom.

– PSEC. [238] – PSEC-1, PSEC-2, PSEC-3 and PSEC-KEMSubmitted by Eiichiro Fujisaki, Tetsutaro Kobayashi, Hikaru Morita, HiroakiOguro, Tatsuaki Okamoto, Satomi Okazaki, David Pointcheval and ShigenoriUchiyama, on behalf of NTT Corp.

– RSA-OAEP. [325] – Revised to RSA-KEM [584]Submitted by Jakob Jonsson and Burton S. Kaliski, Jr, on behalf of RSA.

Digital signature schemes

– ACE Sign. [563]Submitted by Thomas Schweinberger and Victor Shoup, on behalf of IBM.

– ECDSA. [319]Submitted by Don B. Johnson and Simon Blake-Wilson, on behalf of Certicom.

– ESIGN. [244]Submitted by Eiichiro Fujisaki, Tetsutaro Kobayashi, Hikaru Morita, HiroakiOguro, Tatsuaki Okamoto and Satomi Okazaki on behalf of NTT Corp.

– FLASH and SFLASH. [514]Submitted by Jacques Patarin and others, on behalf of Schlumberger.

– QUARTZ. [161]Submitted by Jacques Patarin and others, on behalf of Schlumberger.

– RSA-PSS. [326]Submitted by Jakob Jonsson and Burton S. Kaliski, Jr, on behalf of RSA.

Digital identification schemes

– GPS. [525]Submitted by Guillaume Poupard and others, on behalf of France Telecom, LaPoste and ENS.

Evaluation methodologies

– General Next Bit Predictor. [294]Submitted by Julio César Hernández, José Maŕıa Sierra, J. C. Mex-Perera,Daniel Borrajo, Arturo Ribagorda and Pedro Isasi.

Draft

April

19, 2

004


Draft

April

19, 2

004

Part B

Security evaluation

Book II Part B of this final report was first published under the name ”NESSIE securityreport” as Deliverable D20 of NESSIE.

Draft

April

19, 2

004

42 Book II. Evaluation — Part B. Security evaluation

Table of Contents

Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491.1 NESSIE project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491.2 Security evaluation methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

1.2.1 Evaluation criteria in NESSIE call . . . . . . . . . . . . . . . . . . . . . . 501.2.2 Methodological issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

1.3 Structure of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511.4 The submissions received by NESSIE . . . . . . . . . . . . . . . . . . . . . . . . . 521.5 Some mathematical notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2. Block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.1.1 Block Cipher — A Formal Definition . . . . . . . . . . . . . . . . . . . 562.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.2.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582.2.2 The Block Cipher as a Pseudorandom Permutation . . . . . . . 592.2.3 Classification of attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.2.4 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742.3.1 Feistel ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752.3.2 Substitution-Permutation Networks (SPNs) . . . . . . . . . . . . . . 752.3.3 Resistance against differential and linear cryptanalysis . . . . 762.3.4 Mini-ciphers and reduced rounds . . . . . . . . . . . . . . . . . . . . . . . 762.3.5 Simple as opposed to complicated designs . . . . . . . . . . . . . . . 772.3.6 A separate key-schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772.3.7 The use or otherwise of S-boxes . . . . . . . . . . . . . . . . . . . . . . . . 772.3.8 Ciphers which are developed from well-studied precursors . 772.3.9 Making encryption and decryption identical . . . . . . . . . . . . . 782.3.10 Hash functions as block ciphers . . . . . . . . . . . . . . . . . . . . . . . . 782.3.11 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782.3.12 Block cipher primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.4 64-bit block ciphers considered during Phase II . . . . . . . . . . . . . . . . . 802.4.1 IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.4.2 Khazad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842.4.3 MISTY1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Draft

April

19, 2

004

Table of Contents 43

2.4.4 SAFER++ (64-bit block) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952.4.5 Triple-DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

2.5 128-bit block ciphers considered during Phase II . . . . . . . . . . . . . . . . 1022.5.1 Camellia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032.5.2 RC6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082.5.3 AES (Rijndael) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112.5.4 SAFER++ (128-bit block) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

2.6 Large block ciphers considered during Phase II . . . . . . . . . . . . . . . . . 1192.6.1 RC6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202.6.2 AES Variant (Rijndael-256) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212.6.3 SHACAL-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212.6.4 SHACAL-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

2.7 64-bit block ciphers not selected for Phase II . . . . . . . . . . . . . . . . . . . 1252.7.1 CS-cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1252.7.2 Hierocrypt-L1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1262.7.3 Nimbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282.7.4 NUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

2.8 128-bit block ciphers not selected for Phase II . . . . . . . . . . . . . . . . . . 1302.8.1 Anubis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302.8.2 Grand Cru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312.8.3 Hierocrypt-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322.8.4 Noekeon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1332.8.5 NUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1342.8.6 Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1342.8.7 SC2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

2.9 Comparison of studied block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . 1362.9.1 64-bit block ciphers considered during Phase II . . . . . . . . . . . 1362.9.2 128-bit block ciphers considered during Phase II . . . . . . . . . . 1372.9.3 Large block ciphers considered during Phase II . . . . . . . . . . . 1372.9.4 64-bit block ciphers not selected for Phase II . . . . . . . . . . . . . 1372.9.5 128-bit block ciphers not selected for Phase II . . . . . . . . . . . . 137

3. Stream ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1513.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1513.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

3.2.1 Classification of attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523.2.2 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

3.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563.3.1 Stream ciphers based on feedback shift registers . . . . . . . . . . 1563.3.2 Stream ciphers based on block ciphers . . . . . . . . . . . . . . . . . . 1573.3.3 Pseudorandom number generators based on modular arith-

metic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.3.4 Other stream ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.3.5 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

3.4 Stream cipher primitives considered during Phase II . . . . . . . . . . . . 1583.4.1 BMGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Draft

April

19, 2

004


3.4.2 SNOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603.4.3 SOBER-t16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613.4.4 SOBER-t32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

3.5 Stream cipher primitives not selected for Phase II . . . . . . . . . . . . . . 1673.5.1 LEVIATHAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673.5.2 LILI-128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693.5.3 RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

4. Hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

4.2.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724.2.2 Classification of attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744.2.3 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

4.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764.3.1 Hash functions based on block ciphers . . . . . . . . . . . . . . . . . . 1764.3.2 Hash functions based on modular arithmetic . . . . . . . . . . . . . 1774.3.3 Dedicated hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784.3.4 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

4.4 Hash functions considered during Phase II . . . . . . . . . . . . . . . . . . . . . 1804.4.1 Whirlpool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804.4.2 SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1854.4.3 SHA-256, SHA-384 and SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 189

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

5. Message authentication codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1955.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1955.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

5.2.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1955.2.2 Classification of attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1965.2.3 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

5.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1995.3.1 MACs based on block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . 1995.3.2 MACs based on hash functions . . . . . . . . . . . . . . . . . . . . . . . . . 2005.3.3 MACs based on universal hashing . . . . . . . . . . . . . . . . . . . . . . 2005.3.4 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

5.4 MAC primitives considered during Phase II . . . . . . . . . . . . . . . . . . . . 2015.4.1 Two-Track-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2015.4.2 UMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2055.4.3 CBC-constructions: EMAC and RMAC . . . . . . . . . . . . . . . . . 2085.4.4 HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

5.5 Comparison of studied MAC primitives . . . . . . . . . . . . . . . . . . . . . . . 211

Draft

April

19, 2

004

Table of Contents 45

6. Asymmetric encryption schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2136.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2136.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

6.2.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2136.2.2 The Security Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2156.2.3 Trusted cryptographic problems . . . . . . . . . . . . . . . . . . . . . . . . 2186.2.4 The Random Oracle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2226.2.5 Other models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2226.2.6 Validation of subgroup elements . . . . . . . . . . . . . . . . . . . . . . . . 2236.2.7 Side-channel attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2246.2.8 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2246.2.9 Assessment criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

6.3 KEM-DEM cryptosystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2256.3.1 Hybrid encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2256.3.2 KEM Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2276.3.3 Key derivation functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2296.3.4 DEM Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2316.3.5 Hybrid Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2326.3.6 Assessment criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

6.4 Asymmetric encryption primitives considered during Phase II . . . . 2336.4.1 ACE-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2336.4.2 ECIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2376.4.3 ECIES-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2396.4.4 EPOC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2416.4.5 PSEC-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2446.4.6 RSA-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

6.5 Asymmetric encryption primitives not selected for Phase II . . . . . . 2496.5.1 EPOC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2496.5.2 EPOC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2516.5.3 PSEC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2536.5.4 PSEC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2546.5.5 RSA-OAEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

7. Digital signature schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2597.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2597.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

7.2.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2617.2.2 Intractability assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2647.2.3 Proven security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2707.2.4 Proofs in an idealised world . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2717.2.5 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

7.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2737.3.1 Schemes based on trapdoor one-way functions . . . . . . . . . . . . 2747.3.2 Schemes based on the Discrete Logarithm Problem . . . . . . . 2827.3.3 Schemes with security proven in the “real world” . . . . . . . . . 2967.3.4 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Draft

April

19, 2

004


7.4 Digital signature schemes considered during Phase II . . . . . . . . . . . . 3027.4.1 ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3027.4.2 ESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3057.4.3 SFLASH (new version) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3077.4.4 QUARTZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3097.4.5 RSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

7.5 Digital signature schemes not selected for Phase II . . . . . . . . . . . . . . 3137.5.1 ACE-Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3137.5.2 FLASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3147.5.3 SFLASH (old version) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

8. Digital identification schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3178.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

8.1.1 Identification through Password . . . . . . . . . . . . . . . . . . . . . . . . 3178.1.2 Lamport’s Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

8.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3188.2.1 Passive Attacks and Interactive Proofs . . . . . . . . . . . . . . . . . . 3188.2.2 Trusted Hard Mathematical Problems. . . . . . . . . . . . . . . . . . . 3198.2.3 Protection against Active Attacks . . . . . . . . . . . . . . . . . . . . . . 3208.2.4 Zero-Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3218.2.5 Witness Indistinguishability . . . . . . . . . . . . . . . . . . . . . . . . . . . 3258.2.6 Resettable Zero-Knowledge Proofs . . . . . . . . . . . . . . . . . . . . . . 3268.2.7 Classification of Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3278.2.8 Assessment Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

8.3 Overview of Common Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3288.3.1 Interactive 3-round Identification Protocols . . . . . . . . . . . . . . 3288.3.2 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

8.4 Digital identification schemes considered during Phase II . . . . . . . . 3298.4.1 Fiat-Shamir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3298.4.2 Schnorr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3308.4.3 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3318.4.4 GQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

A. Side-channel attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337A.1 Passive Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

A.1.1 Types of Information Leakage . . . . . . . . . . . . . . . . . . . . . . . . . . 338A.1.2 Simple Side-Channel Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 339A.1.3 Differential Side-Channel Attacks . . . . . . . . . . . . . . . . . . . . . . . 341A.1.4 Error Message Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342A.1.5 Consideration of Hash-function, MACs and Stream Ciphers343

A.2 Active Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343A.2.1 Fault Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343A.2.2 Chosen Modulus Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346A.2.3 Other attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346A.2.4 Preventing fault attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Draft

April

19, 2

004

List of Tables 47

List of Tables

2.1 Comparison of attack requirements on reduced-round IDEA . . . . . . . . . 842.2 Comparison of attack requirements on IDEA for weak-key classes. . . . . 852.3 Subkey Mapping Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912.4 Complexity of Linear Attacks on SAFER++ (64-bit block) . . . . . . . . . . 1002.5 Differential/Linear Cryptanalysis of RC6 [143] . . . . . . . . . . . . . . . . . . . . . 1092.6 Multiple Linear Cryptanalysis of RC6 [143] . . . . . . . . . . . . . . . . . . . . . . . . 1102.7 Complexity of Linear Attacks on SAFER++ . . . . . . . . . . . . . . . . . . . . . . . 1182.8 Attacks by Nakahara et al. for SAFER++ (128-bit block) and Similar

Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192.9 Piret’s Integral Attacks on SAFER++ (128-bit block). . . . . . . . . . . . . . . 1192.10 Multiset and Boomerang Attacks on SAFER++ (128-bit block) by

Biryukov et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202.11 Attack Requirements for Hierocrypt-3 and Hierocrypt-L1 . . . . . . . . . . . . 1282.12 Designers Claims of Security — Known Attacks . . . . . . . . . . . . . . . . . . . . 1312.13 Data/Time Complexity of Attacks on Q for Different Key Sizes . . . . . . 1352.14 A summary of each 64-bit block cipher selected for Phase II . . . . . . . . . 1382.14 (continued) A summary of each 64-bit block cipher sel

final report of european project number ist-1999-12324 ... · new european schemes for signatures,...

Documents