285 Pages
English
Gain access to the library to view online
Learn more

Description

Project Number IST-2000-12324 Project Title NESSIE Deliverable Type Report Security Class Public Deliverable Number D20 Title of Deliverable NESSIE security report Document Reference NES/DOC/ENS/WP5/D20/1 Contractual Date of Delivery Y3 M9 Actual Date of Delivery Y3 M9 Editors ENS Abstract A first security evaluation was published under deliverable number D13 and has served as a basis of a selection of the primitives that have been studied more in detail. This report summarizes the new results together with a comprehensive overview of the security evaluation made by the NESSIE consortium. Keywords NESSIE, Security evaluation. Version 1.0 October 21, 2002

  • nessie deliverable

  • keywords nessie

  • bit block

  • submitted primitives

  • nessie security

  • ciphers considered during

  • assessment process

  • nessie project


Subjects

Informations

Published by
Reads 33
Language English
Document size 1 MB

Project Number IST-2000-12324
Project Title NESSIE
Deliverable Type Report
Security Class Public
Deliverable Number D20
Title ofDeliverable NESSIE security report
Document Reference NES/DOC/ENS/WP5/D20/1
Contractual Date ofDelivery Y3 M9
Actual Date ofDelivery Y3 M9
Editors ENS
Abstract A flrst security evaluation was published under
deliverable number D13 and has served as a basis of
a selection of the primitives that have been studied
more in detail. This report summarizes the new
results together with a comprehensive overview of the
security evaluation made by the NESSIE consortium.
Keywords NESSIE, Security evaluation.
Version 1.0
October 21, 2002yNESSIE security report
1 1 1 1B. Preneel , A. Biryukov , E. Oswald , B. van Rompay ,
2 2L. Granboulan , E. Dottax ,
3 3 3S. Murphy , A. Dent , J. White ,
4 4 4 4M. Dichtl , S. Pyka , M. Schafheutle , P. Serf ,
5 5 5E. Biham , E. Barkan , O. Dunkelman ,
6 6M. Ciet , F. Sica ,
7,8 7L. Knudsen , H. Raddum .
October 21, 2002
Version 1.0
yThe work described in this report has been supported by the Commission of the European Communities
through the IST program under contract IST-1999-12324. The information in this document is provided
as is, and no warranty is given or implied that the information is flt for any particular purpose. The
user thereof uses the information at its sole risk and liability.
1KatholiekeUniversiteitLeuven,Dept. Elektrotechniek-ESAT/COSIC,KasteelparkArenberg10,B-3001
Leuven-Heverlee, Belgium
2 ¶Ecole Normale Sup¶erieure, D¶epartement d’Informatique, 45 rue d’Ulm, Paris 75230 Cedex 05, France
3Royal Holloway, Information Security Group, Egham, Surrey TW20 0EX, UK
4Siemens AG, Otto-Hahn-Ring 6, Munc˜ hen 81732, Germany
5Technion, Computer Science Dept., Haifa 32000, Israel
6Universit¶e Catholique de Louvain, Dept. ELEC, Place du Levant 3, B-1348 Louvain-la-Neuve, Belgium
7Universitetet i Bergen, Dept. of Informatics, PO Box 7800 Thormoehlensgt. 55, Bergen 5020, Norway
8Tech. Univ. of Denmark, Dept.of Mathematics, Building 303, DK-2800 Lyngby, DenmarkExecutive Summary
NESSIE security report
(NESSIE Deliverable D20)
The NESSIE project is a three year project (2000-2002) that is funded by the European
Union’s Fifth Framework Programme. The main objective of the NESSIE project is to
put forward a portfolio of strong cryptographic primitives of various types. An open
call in March 2000 led to the submission of forty cryptographic primitives to the NESSIE
project. TheNESSIEprojectisevaluating(withsomeexternalassistance)thesesubmitted
primitives from both a security and performance perspective. This document gives the
collective view of the NESSIE partners about the submissions from a security perspective.
The NESSIE evaluation process is an open process. Thus as part of the evaluation
process, the NESSIE project welcomes comments about the submitted primitives and the
evaluation process, including this report. To facilitate the open evaluation process, there
are to be four NESSIE workshops. The flrst workshop was dedicated to the presentation of
thesubmittedprimitivesandthesecondworkshopwasdedicatedtoearlyresultsconcerning
the primitives. The third workshop will be dedicated to new results and will also discuss
version 1.0 of this report. A fourth NESSIE workshop is planned to take place at the end
of the project.
This document forms deliverable D20 of the NESSIE project. Version 1.0 is published
to be available for comments before the Third Workshop and version 2.0 will be
the flnal security report.
iContents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
1 Introduction 1
1.1 NESSIE project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Security evaluation methodology . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Ev criteria in NESSIE call. . . . . . . . . . . . . . . . . . . 2
1.2.2 Methodological issues . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Structure of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 The submissions received by NESSIE . . . . . . . . . . . . . . . . . . . . . 5
1.5 The Project Industrial Board . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Mathematical notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Block ciphers 8
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Classiflcation of attacks . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 Feistel ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2 Substitution-Permutation Networks (SPNs) . . . . . . . . . . . . . 25
2.3.3 Resistance against difierential and linear cryptanalysis . . . . . . . 26
2.3.4 Mini-ciphers and reduced rounds . . . . . . . . . . . . . . . . . . . 26
2.3.5 Simple as opposed to complicated designs . . . . . . . . . . . . . . 27
2.3.6 A separate key-schedule . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.7 The use or otherwise of S-boxes . . . . . . . . . . . . . . . . . . . . 27
2.3.8 Ciphers which are developed from well-studied precursors . . . . . . 28
2.3.9 Making encryption and decryption identical . . . . . . . . . . . . . 28
2.3.10 Hash functions as block ciphers . . . . . . . . . . . . . . . . . . . . 28
2.3.11 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.12 Block cipher primitives . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4 64-bit block ciphers considered during Phase II. . . . . . . . . . . . . . . . 30
ii2.4.1 IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.2 Khazad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.3 MISTY1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.4 Safer++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4564
2.4.5 Triple-DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.5 128-bit block ciphers considered during Phase II . . . . . . . . . . . . . . . 52
2.5.1 Camellia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.5.2 RC6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5.3 AES (Rijndael) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.5.4 Safer++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64128
2.6 Large block ciphers considered during Phase II . . . . . . . . . . . . . . . . 64
2.6.1 RC6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.6.2 AES Variant (Rijndael-256) . . . . . . . . . . . . . . . . . . . . . . 66
2.6.3 SHACAL-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.6.4 SHACAL-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.7 64-bits block ciphers not selected for Phase II . . . . . . . . . . . . . . . . 71
2.7.1 CS-cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.7.2 Hierocrypt-L1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.7.3 Nimbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.7.4 Nush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.8 128-bits block ciphers not selected for Phase II . . . . . . . . . . . . . . . . 75
2.8.1 Anubis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.8.2 Grand Cru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.8.3 Hierocrypt-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.8.4 Noekeon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.8.5 Nush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.8.6 Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.8.7 SC2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.9 Comparison of studied block ciphers. . . . . . . . . . . . . . . . . . . . . . 83
2.9.1 64-bit block ciphers considered during Phase II . . . . . . . . . . . 83
2.9.2 128-bit block Phase II . . . . . . . . . . . 83
2.9.3 Large block ciphers considered during Phase II . . . . . . . . . . . . 83
2.9.4 64-bit block not selected for Phase II . . . . . . . . . . . . . 87
2.9.5 128-bit block ciphers not for Phase II . . . . . . . . . . . . 87
3 Stream ciphers 89
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.2.1 Classiflcation of attacks . . . . . . . . . . . . . . . . . . . . . . . . 90
3.2.2 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . 94
3.3.1 Stream ciphers based on feedback shift registers . . . . . . . . . . . 94
3.3.2 based on block ciphers . . . . . . . . . . . . . . . . 95
iii3.3.3 Pseudorandom number generators based on modular arithmetic . . 95
3.3.4 Other stream ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.3.5 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.4 Stream cipher primitives considered during Phase II . . . . . . . . . . . . . 96
3.4.1 BMGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.4.2 SNOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.4.3 SOBER-t16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.4.4 SOBER-t32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.5 Stream cipher primitives not selected for Phase II . . . . . . . . . . . . . . 104
3.5.1 LEVIATHAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.5.2 LILI-128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.5.3 RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4 Hash functions 106
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2.2 Classiflcation of attacks . . . . . . . . . . . . . . . . . . . . . . . . 107
4.2.3 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . 110
4.3.1 Hash functions based on block ciphers . . . . . . . . . . . . . . . . 110
4.3.2 Hash based on modular arithmetic . . . . . . . . . . . . . 111
4.3.3 Custom-designed hash functions . . . . . . . . . . . . . . . . . . . . 111
4.3.4 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.4 Hash Functions considered during Phase II . . . . . . . . . . . . . . . . . . 113
4.4.1 Whirlpool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.4.2 SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.4.3 SHA-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5 Message authentication codes 125
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.2.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.2.2 Classiflcation of attacks . . . . . . . . . . . . . . . . . . . . . . . . 126
5.2.3 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . 128
5.3.1 MACs based on block ciphers . . . . . . . . . . . . . . . . . . . . . 128
5.3.2 MACS based on hash functions . . . . . . . . . . . . . . . . . . . . 129
5.3.3 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.4 MAC primitives considered during Phase II . . . . . . . . . . . . . . . . . 129
5.4.1 Two-Track-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.4.2 UMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
iv5.4.3 CBC-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.4.4 HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6 Asymmetric encryption schemes 140
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.2.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.2.2 The Security Models . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.2.3 Trusted cryptographic problems . . . . . . . . . . . . . . . . . . . . 145
6.2.4 The Random Oracle Model . . . . . . . . . . . . . . . . . . . . . . 146
6.2.5 Other models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.2.6 Side-channel attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.2.7 Assessment criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.3 KEM-DEM cryptosystems . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.3.1 Hybrid encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.3.2 KEM Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.3.3 DEMy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.3.4 Hybrid Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.3.5 Assessment criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.4 Primitives considered during Phase II . . . . . . . . . . . . . . . . . . . . . 156
6.4.1 ACE-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.4.2 ECIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.4.3 ECIES-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.4.4 EPOC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.4.5 PSEC-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.4.6 RSA-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.5 Primitives not considered during Phase II . . . . . . . . . . . . . . . . . . 170
6.5.1 EPOC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.5.2 EPOC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
6.5.3 PSEC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.5.4 PSEC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.5.5 RSA-OAEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7 Digital signature schemes 182
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
7.2.1 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
7.2.2 Intractability assumptions . . . . . . . . . . . . . . . . . . . . . . . 186
7.2.3 Proven security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
7.2.4 Proofs in an idealized world . . . . . . . . . . . . . . . . . . . . . . 194
7.2.5 Side channel attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 196
v7.2.6 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . 197
7.3.1 Schemes based on trapdoor one-way functions . . . . . . . . . . . . 198
7.3.2 Sc based on the Discrete Logarithm . . . . . . . . . . . . . . 205
7.3.3 Schemes with security proven in the \real world" . . . . . . . . . . 218
7.3.4 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.4 Digital signature schemes considered during Phase II . . . . . . . . . . . . 220
7.4.1 ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.4.2 ESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
7.4.3 SFLASHv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
7.4.4 QUARTZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
7.4.5 RSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
7.5 Digital signature schemes not selected for Phase II . . . . . . . . . . . . . . 229
7.5.1 ACE Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7.5.2 FLASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
7.5.3 SFLASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
7.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
8 Digital identiflcation schemes 233
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.2 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.2.1 Minimal security properties . . . . . . . . . . . . . . . . . . . . . . 234
8.2.2 Proof of security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.2.3 Trusted hard mathematical problems . . . . . . . . . . . . . . . . . 235
8.2.4 Classiflcation of attacks . . . . . . . . . . . . . . . . . . . . . . . . 235
8.2.5 Assessment process . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
8.3 Overview of the common designs . . . . . . . . . . . . . . . . . . . . . . . 237
8.3.1 Schnorr’s Identiflcation Scheme . . . . . . . . . . . . . . . . . . . . 237
8.3.2 Current standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8.4 Digital identiflcation schemes considered during Phase II . . . . . . . . . . 238
8.4.1 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8.4.2 GQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Bibliography 242
viChapter 1
Introduction
1.1 NESSIE project
The project is a three year project (2000-2002) that is funded by the Euro-
pean Union’s Fifth Framework Programme. The main objective of the NESSIE project
is to put forward a portfolio of strong cryptographic primitives of various types. Fur-
ther details about the NESSIE project can be found at the NESSIE website http://www.
cryptonessie.org/.
The start of the NESSIE project was an open call [311] for the submission of crypto-
graphic primitives as well as for evaluation methodologies for these primitives. This call
includesarequestforthesubmissionofblockciphers(asfortheAEScall),butalsoofother
cryptographic primitives includinghash functions, stream ciphers, anddigital signature al-
gorithms. The call also asked for evaluation methodologies for these primitives. The scope
of the call was deflned in conjunction with the project industry board, and was published
in March 2000. This call resulted in forty submissions. The NESSIE project aims to assess
thesesubmissionswith thegoal of producingaportfolio of cryptographicprimitives foruse
in difierent environments. The NESSIE project proposes to disseminate the project results
widely and to build consensus based on these results by using the appropriate bodies: a
project industry board, NESSIE workshops, the 5th Framework programme, and various
standardisation bodies.
The NESSIE project has been divided into two phases. In the flrst phase of the secu-
rity evaluation, these submissions were analysed by the NESSIE partners. The NESSIE
partners have also received external comments for some submissions. The outcome of the
flrst phase was a preliminary assessment of all submissions: a security evaluation [314] and
a performance evaluation [313]. This was used to decide which of the submissions are to
be considered in the second phase [312]. In the second phase, the remaining submissions
were subject to more detailed scrutiny to produce the portfolio. This report summarizes
all the security evaluation of the submissions and is the conclusion the the second phase
0Coordinator for this chapter: ENS | Louis Granboulan
12 CHAPTER 1. INTRODUCTION
of security evaluation. The NESSIE project also compiles a performance evaluation of the
submissions. This security report together with the performance report form the basis of
the decision as to which primitives should be part of the NESSIE portfolio.
The NESSIE evaluation process is an open process. Thus as part of the evaluation
process, the NESSIE project welcomes comments about the submitted primitives and the
evaluation process, including this report. To facilitate the open evaluation process, there
aretobefourNESSIEworkshops. TheflrstNESSIEworkshoptookplaceon13-14Novem-
ber 2000 at Katholieke Universiteit Leuven (Belgium) in which the submitted primitives
were presented. The second NESSIE workshop took place on 12-13 September 2001 at
Royal Holloway, University of London (UK) in which early results concerning the primi-
tives were presented. The third NESSIE workshop takes place on 6-7 November 2002 at
Siemens AG, Munich (Germany) at which new results concerning the primitives are to be
presented. A fourth NESSIE workshop is planned to take place at the end of the project.
1.2 Security evaluation methodology
The NESSIE project has attempted to deflne a high{level methodology to compare in a
fair and acceptable way the submitted primitives. This methodology may evolve according
to technical advances, remarks of the NESSIE members, Industry Board or cryptographic
experts, and with problems encountered. However it should be noted that it is impossible
to produce a deflnitive security methodology. Cryptographic primitives with completely
inadequate security can often be identifled. However, for other cryptographic primitives,
thesituationisnothinglikeasclear-cut. Thereisneitheranautomaticmethodofassessing
the security of such a primitive nor a general consensus on the relative importance of
difierent security criteria. The few previous initiatives that have undertaken a similar task
to the NESSIE project, such as AES, have been more limited in scope and have reached
a subjective judgement by experts on the security of such primitives. We flrst give the
evaluation criteria specifled in the NESSIE call [311] and then a list of important issues
that NESSIE has considered in making its security evaluations of a submitted primitive.
This list is extensive but not complete.
1.2.1 Evaluation criteria in NESSIE call
1. An attack should be at least as di–cult as the generic attacks against the type of
primitive (exhaustive search, birthday attack etc.).
2. Primitives will be evaluated against the security claims of the submitter. An at-
tack requiring lower computing resources than claimed would usually disqualify the
submission.
3. Primitives will be evaluated within the stated environment. Thus, consideration of
vulnerability to side channel attacks (e.g. timing attacks, power analysis) may be
appropriate.