Suggestions for Hardware Evaluation of Cryptographic Algorithms Frank K. G¨ urkaynak Microelectronics Design Center, ETH Z¨ urich 6 July 2012
My Goal To improve the quality of hardware evaluations for crypto algorithms. Microelectronics Design Center Department of Information Technology 2 / 26 Zurich and Electrical Engineering
My Goal To improve the quality of hardware evaluations for crypto algorithms. Problems Many degrees of freedom in Hardware Design Microelectronics Design Center Department of Information Technology 2 / 26 Zurich and Electrical Engineering
My Goal To improve the quality of hardware evaluations for crypto algorithms. Problems Many degrees of freedom in Hardware Design Is costly (time/money) not many are performed Microelectronics Design Center Department of Information Technology 2 / 26 Zurich and Electrical Engineering
My Goal To improve the quality of hardware evaluations for crypto algorithms. Problems Many degrees of freedom in Hardware Design Is costly (time/money) not many are performed Different goals, technologies, metrics Microelectronics Design Center Department of Information Technology 2 / 26 Zurich and Electrical Engineering
My Goal To improve the quality of hardware evaluations for crypto algorithms. Problems Many degrees of freedom in Hardware Design Is costly (time/money) not many are performed Different goals, technologies, metrics Studies are therefore not comparable Microelectronics Design Center Department of Information Technology 2 / 26 Zurich and Electrical Engineering
My Experience: AES Rijndael and Serpent http://dx.doi.org/10.1007/3-540-36400-5_12 Microelectronics Design Center Department of Information Technology 3 / 26 Zurich and Electrical Engineering
My Experience: E-stream Microelectronics Design Center Department of Information Technology 4 / 26 Zurich and Electrical Engineering
My Experience: SHA-3 Collaboration with K. Gaj http://dx.doi.org/10.1007/978-3-642-15031-9_17 Microelectronics Design Center Department of Information Technology 5 / 26 Zurich and Electrical Engineering
So What is Wrong? Some observations Hardware design needs constraints! Hardware design is an exercise in finding the best circuit that satisfies given constraints . Microelectronics Design Center Department of Information Technology 6 / 26 Zurich and Electrical Engineering
So What is Wrong? Some observations Hardware design needs constraints! Hardware design is an exercise in finding the best circuit that satisfies given constraints . Until now Implementers choose some constraints arbitrarily Results are not comparable between studies Can not make conlusions Microelectronics Design Center Department of Information Technology 6 / 26 Zurich and Electrical Engineering
So What is Wrong? Some observations Hardware design needs constraints! Hardware design is an exercise in finding the best circuit that satisfies given constraints . Until now Implementers choose some constraints arbitrarily Results are not comparable between studies Can not make conlusions Any constraint is better than none The exact constraint is not very important. Microelectronics Design Center Department of Information Technology 6 / 26 Zurich and Electrical Engineering
What do we suggest ? To improve the quality of hardware evaluations for crypto algorithms. Microelectronics Design Center Department of Information Technology 7 / 26 Zurich and Electrical Engineering
What do we suggest ? To improve the quality of hardware evaluations for crypto algorithms. Four suggestions Define a standard testbench . Specify a target application scenario. State reference IC technology and FPGA device for comparisons. Submitters should include HDL code. Microelectronics Design Center Department of Information Technology 7 / 26 Zurich and Electrical Engineering
#1: Standard Testbench The call should include a standard testbench for hardware implementations which should read the same KAT files as software models. Microelectronics Design Center Department of Information Technology 8 / 26 Zurich and Electrical Engineering
Why a Standard Testbench ? Testbench determines the interface I/O bit-widths Processing order Additional functionality Microelectronics Design Center Department of Information Technology 9 / 26 Zurich and Electrical Engineering
Why a Standard Testbench ? Testbench determines the interface I/O bit-widths Processing order Additional functionality Removes ambiguity about auxillary (non-vital) functions, which may have non-negligable impact on results Microelectronics Design Center Department of Information Technology 9 / 26 Zurich and Electrical Engineering
#2: Define Application Scenario The call should include define an application scenario for hardware designs that sets clear constraints for the circuits. Microelectronics Design Center Department of Information Technology 10 / 26 Zurich and Electrical Engineering
Hardware Design Targets Differ Microelectronics Design Center Department of Information Technology 11 / 26 Zurich and Electrical Engineering
Scenario Examples Some suggestions Sensor Node Messages of 32 to 512 bits Throughput 100 kbits/s Key change every 3 months Priority energy consumption Second priority small area Microelectronics Design Center Department of Information Technology 12 / 26 Zurich and Electrical Engineering
Scenario Examples Some suggestions Sensor Node Embedded core Messages of 32 bits to 4 Mbits Throughput 100 Mbits/s Key change every 10ms Priority energy/bit Second priority small area Microelectronics Design Center Department of Information Technology 12 / 26 Zurich and Electrical Engineering
Scenario Examples Some suggestions Sensor Node Embedded core Data Center Messages of 2 10 bits to 2 64 bits Throughput 10 Gbits/s Key change every 2 14 bits Priority throughput per area Second priority power Microelectronics Design Center Department of Information Technology 12 / 26 Zurich and Electrical Engineering
Why One Scenario Should Suffice Defining more than one scenario Is more work Preparing good scenarios is difficult. Microelectronics Design Center Department of Information Technology 13 / 26 Zurich and Electrical Engineering
Why One Scenario Should Suffice Defining more than one scenario Is more work Preparing good scenarios is difficult. Will result in fewer data to compare Groups will choose one of the scenarios, reduce data points Microelectronics Design Center Department of Information Technology 13 / 26 Zurich and Electrical Engineering
Why One Scenario Should Suffice Defining more than one scenario Is more work Preparing good scenarios is difficult. Will result in fewer data to compare Groups will choose one of the scenarios, reduce data points 2 or 3 will also not be enough There will always be an argument for more . Microelectronics Design Center Department of Information Technology 13 / 26 Zurich and Electrical Engineering
Why One Scenario Should Suffice Defining more than one scenario Is more work Preparing good scenarios is difficult. Will result in fewer data to compare Groups will choose one of the scenarios, reduce data points 2 or 3 will also not be enough There will always be an argument for more . Suggestion: One rather conservative scenario Microelectronics Design Center Department of Information Technology 13 / 26 Zurich and Electrical Engineering
Standard does not Mean Universal Actual applications will vary The goal is to achieve uniform results Not necessarily optimal for all applications. Consistency is more important. Microelectronics Design Center Department of Information Technology 14 / 26 Zurich and Electrical Engineering
Standard does not Mean Universal Actual applications will vary The goal is to achieve uniform results Not necessarily optimal for all applications. Consistency is more important. Not possible to account for everything! It should not be the goal of the call to do so. Microelectronics Design Center Department of Information Technology 14 / 26 Zurich and Electrical Engineering
Standard does not Mean Universal Actual applications will vary The goal is to achieve uniform results Not necessarily optimal for all applications. Consistency is more important. Not possible to account for everything! It should not be the goal of the call to do so. Free to evaluate different options Every evaluation should use standard, but free to explore other options. Microelectronics Design Center Department of Information Technology 14 / 26 Zurich and Electrical Engineering
#3: Choose a Reference Technology The call should determine a reference technology and standard cell library for ASIC implementations and a reference FPGA device to be used for comparisons. Microelectronics Design Center Department of Information Technology 15 / 26 Zurich and Electrical Engineering
Even if Same Technology is Used Significant differences depending on: Manufacturer Performance of UMC != ST != TSMC Microelectronics Design Center Department of Information Technology 16 / 26 Zurich and Electrical Engineering
Recommend
More recommend
