cs548_ advanced information security 20103272 jong heon, park / 20103616 hyun woo, cho evaluation of...
Post on 20-Jan-2016
226 Views
Preview:
TRANSCRIPT
CS548_ADVANCED INFORMATION
SECURITY
20103272 Jong Heon Park 20103616 Hyun Woo Cho
Evaluation of Hardware Performance for the SHA-3 Candidates Using SASEBO-GII
Paper Presentation 2
Contents
Introduction Before the paper Evaluation Platform Design Strategy Evaluation Criteria Conclusion References
2 33
Paper Introduction
Evaluation of Hardware Performance for the SHA-3 Candidates Using SASEBO-GII Jan 2010
They propose following issues for a fair evaluation Evaluation environment (platform) Implementation method (design
strategy) Performance comparison method
(criteria)
Kazuyuki Kobayashi Jun Ikegami Shinrsquoichiro Kazuyuki Kobayashi Jun Ikegami Shinrsquoichiro Matsuo Matsuo Kazuo Sakiyama Kazuo OhtaKazuo Sakiyama Kazuo Ohta
Author
3 33
Before the paper
httpcsrcnistgovgroupsSThashsha-3indexhtml
4 33
Evaluation Platform
SASEBO (Side-channel Attack Standard Evaluation
Board) The purpose of side-channel attack
experiments within a single cryptographic circuit
SASEBO-GII The purpose of additional experiments for
security evaluation for a comprehensive cryptographic system
5 33
Evaluation Platform
Fig 1 SASEBO-GII
6 33
Evaluation Platform
Fig 2 Evaluation Environment Using SASEBO-GII
7 33
Evaluation Platform
Protocol between two FPGAs Init initialize a hash function in the
cryptographic FPGA Load amp Fetch
transmitting and receiving the message data and the hash value
Ack response signal for the load amp fetch signals
idata odata input output data (16bit) EoM end of message signal
8 33
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Contents
Introduction Before the paper Evaluation Platform Design Strategy Evaluation Criteria Conclusion References
2 33
Paper Introduction
Evaluation of Hardware Performance for the SHA-3 Candidates Using SASEBO-GII Jan 2010
They propose following issues for a fair evaluation Evaluation environment (platform) Implementation method (design
strategy) Performance comparison method
(criteria)
Kazuyuki Kobayashi Jun Ikegami Shinrsquoichiro Kazuyuki Kobayashi Jun Ikegami Shinrsquoichiro Matsuo Matsuo Kazuo Sakiyama Kazuo OhtaKazuo Sakiyama Kazuo Ohta
Author
3 33
Before the paper
httpcsrcnistgovgroupsSThashsha-3indexhtml
4 33
Evaluation Platform
SASEBO (Side-channel Attack Standard Evaluation
Board) The purpose of side-channel attack
experiments within a single cryptographic circuit
SASEBO-GII The purpose of additional experiments for
security evaluation for a comprehensive cryptographic system
5 33
Evaluation Platform
Fig 1 SASEBO-GII
6 33
Evaluation Platform
Fig 2 Evaluation Environment Using SASEBO-GII
7 33
Evaluation Platform
Protocol between two FPGAs Init initialize a hash function in the
cryptographic FPGA Load amp Fetch
transmitting and receiving the message data and the hash value
Ack response signal for the load amp fetch signals
idata odata input output data (16bit) EoM end of message signal
8 33
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Paper Introduction
Evaluation of Hardware Performance for the SHA-3 Candidates Using SASEBO-GII Jan 2010
They propose following issues for a fair evaluation Evaluation environment (platform) Implementation method (design
strategy) Performance comparison method
(criteria)
Kazuyuki Kobayashi Jun Ikegami Shinrsquoichiro Kazuyuki Kobayashi Jun Ikegami Shinrsquoichiro Matsuo Matsuo Kazuo Sakiyama Kazuo OhtaKazuo Sakiyama Kazuo Ohta
Author
3 33
Before the paper
httpcsrcnistgovgroupsSThashsha-3indexhtml
4 33
Evaluation Platform
SASEBO (Side-channel Attack Standard Evaluation
Board) The purpose of side-channel attack
experiments within a single cryptographic circuit
SASEBO-GII The purpose of additional experiments for
security evaluation for a comprehensive cryptographic system
5 33
Evaluation Platform
Fig 1 SASEBO-GII
6 33
Evaluation Platform
Fig 2 Evaluation Environment Using SASEBO-GII
7 33
Evaluation Platform
Protocol between two FPGAs Init initialize a hash function in the
cryptographic FPGA Load amp Fetch
transmitting and receiving the message data and the hash value
Ack response signal for the load amp fetch signals
idata odata input output data (16bit) EoM end of message signal
8 33
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Before the paper
httpcsrcnistgovgroupsSThashsha-3indexhtml
4 33
Evaluation Platform
SASEBO (Side-channel Attack Standard Evaluation
Board) The purpose of side-channel attack
experiments within a single cryptographic circuit
SASEBO-GII The purpose of additional experiments for
security evaluation for a comprehensive cryptographic system
5 33
Evaluation Platform
Fig 1 SASEBO-GII
6 33
Evaluation Platform
Fig 2 Evaluation Environment Using SASEBO-GII
7 33
Evaluation Platform
Protocol between two FPGAs Init initialize a hash function in the
cryptographic FPGA Load amp Fetch
transmitting and receiving the message data and the hash value
Ack response signal for the load amp fetch signals
idata odata input output data (16bit) EoM end of message signal
8 33
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Platform
SASEBO (Side-channel Attack Standard Evaluation
Board) The purpose of side-channel attack
experiments within a single cryptographic circuit
SASEBO-GII The purpose of additional experiments for
security evaluation for a comprehensive cryptographic system
5 33
Evaluation Platform
Fig 1 SASEBO-GII
6 33
Evaluation Platform
Fig 2 Evaluation Environment Using SASEBO-GII
7 33
Evaluation Platform
Protocol between two FPGAs Init initialize a hash function in the
cryptographic FPGA Load amp Fetch
transmitting and receiving the message data and the hash value
Ack response signal for the load amp fetch signals
idata odata input output data (16bit) EoM end of message signal
8 33
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Platform
Fig 1 SASEBO-GII
6 33
Evaluation Platform
Fig 2 Evaluation Environment Using SASEBO-GII
7 33
Evaluation Platform
Protocol between two FPGAs Init initialize a hash function in the
cryptographic FPGA Load amp Fetch
transmitting and receiving the message data and the hash value
Ack response signal for the load amp fetch signals
idata odata input output data (16bit) EoM end of message signal
8 33
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Platform
Fig 2 Evaluation Environment Using SASEBO-GII
7 33
Evaluation Platform
Protocol between two FPGAs Init initialize a hash function in the
cryptographic FPGA Load amp Fetch
transmitting and receiving the message data and the hash value
Ack response signal for the load amp fetch signals
idata odata input output data (16bit) EoM end of message signal
8 33
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Platform
Protocol between two FPGAs Init initialize a hash function in the
cryptographic FPGA Load amp Fetch
transmitting and receiving the message data and the hash value
Ack response signal for the load amp fetch signals
idata odata input output data (16bit) EoM end of message signal
8 33
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Platform
Performance depends on communication overhead between two FPGAs
We use a practical interface that can support a 16-bit data communication in 3 cycles
It takes 3(25616) = 48 cycles for 256-bit data But we ignore the overhead to evaluate
hash core
9 33
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Design Strategy
Specification of Data Input to Cryptographic FPGA Message Padding
Input data must be a multiple of the block size
EoM (End of Message) Some candidates need to know where is end
of data Bit Length of Message
Bit length is included in idatararr candidates which need the information takes more time than the others
10 33
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Design Strategy
Architectures of Cryptographic FPGA Fully Autonomous
Stores all of the intermediate values in register
an implementation assuming to be used in a real system
11 33
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Design Strategy
Architectures of Cryptographic FPGA External Memory
Only the data necessary for executing are stored register the other data are stored external memory
Low-cost but it makes overhead cycles
not suitable for high-speed implementation
12 33
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Design Strategy
Architectures of Cryptographic FPGA Core Functionality
Only the core part of a hash function
Used for estimating performance under ideal interface where the overhead of the data access is ignored
13 33
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Design Strategy
Performance Throughput
Input Block Size = the size of input data Number of Clock Cycles which is necessary to
hash the data Max Clock Frequency = 1critical path delay Increasing Max Clock Frequency
Decreasing Number of Clock Cycles
Improve Throughp
ut
14 33
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Design Strategy
Technique to Improve Throughput Retiming Transformation holds down the critical
path delay by averaging a processing time
After Transformation critical path consists of two adders Therefore the maximum clock frequency improves
Before
After
15 33
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Design Strategy
Technique to Improve Throughput Unfolding Transformation decreases the total
number of clock cycles
After Transformation the DFG performs operations in one cycle Although maximum clock frequency becomes lower throughput improves
Before
After
16 33
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Design Strategy
How to deal with these optimization techniques
Applying the Unfolding Transformation
17 33
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Items Eight SHA-3 hash candidates on the
cryptographic FPGA Check the hardware performance(speed) and
cost Speed performance
Latency throughput Cost
Number of slices registers LUTs and size of a RAM
High throughput with a low hardware cost
Evaluation Criteria18 33
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Metrics Hashing process for each data with a input
block sizes Uses the result as the next input data Clock cycles Hashing |M|-bit data
Number of hash core operation
Evaluation Criteria19 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
Evaluation Criteria20 33
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Metrics
Number of clocks used to input data
To execute hashing process in the core
To perform the final calculation process
To output the hash result
- Only executed when outputting the result
Evaluation Criteria21 33
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Metrics Throughput
Latency See this
equation
Latency is an important metrics for a short message
Evaluation Criteria22 33
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Metrics Throughput
When |Mp| is sufficiently largeShort massage for authentication
Long massage
Evaluation Criteria23 33
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Evaluation Metrics
Long Massage(Throuhput)
Short Massage(Latency)
Interface + Core
Core Function Block
Evaluation Criteria24 33
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Result for Eight SHA-3 Candidates Interface overhead
Evaluation Criteria25 33
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Result for Eight SHA-3 Candidates Core Function Block
Evaluation Criteria26 33
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Performance Results of the SHA-3 Candidates
Evaluation Criteria27 33
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Hardware Costs of the SHA-3 Candidates on Virtex5
Evaluation Criteria28 33
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Latency of Hash Function including interface
Evaluation Criteria29 33
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Latency of Core Function Block for Short Massage
Likely to be a Bottle Neck
Performance of Interface is important part
Evaluation Criteria30 33
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Conclusions
Propose a consistent evaluation criteria Basic design of an evaluation
environment using SASEBO-GII(interface spec architecturehellip)
Propose evaluation items(speed costhellip) Implement eight SHA-3 candidates Future work
Rest of the SHA-3 candidates Evaluation for low power device(RFID tags)
31 33
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
References
1 National Institute of Standards and Technology (NIST) ldquoCryptographic Hash
Algorithm Competitionrdquo httpcsrcnistgovgroupsSThashsha-3index
html
2 S Tillich M Feldhofer M Kirschbaum T Plos J -M Schmidt and A Szekely
ldquoHigh-Speed Hardware Implementations of BLAKE Blue Midnight Wish Cube-
Hash ECHO Fugue Groslashstl Hamsi JH Keccak Luffa Shabal SHAvite-3 SIMD
and Skeinrdquo Cryptology ePrint Archive Report 2009510 2009
3 A H Namin and M A Hasan ldquoHardware Implementation of the Compression
Function for Selected SHA-3 Candidatesrdquo CACR 2009-28 (2009)
4 B Baldwin A Byrne M Hamilton N Hanley R P McEvoy W Pan and
W P Marnane ldquoFPGA Implementations of SHA-3 CandidatesCubeHash Groslashstl
Lane Shabal and Spectral Hashrdquo Cryptology ePrint Archive Report 2009342
2009
32 33
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
References
5 B Jungk S Reith and J Apfelbeck ldquoOn Optimized FPGA Implementations of
the SHA-3 Candidate Groslashstlrdquo Cryptology ePrint Archive Report 2009206 2009
6 ldquoNational Institute of Advanced Industrial Science and Technology (AIST) Research
Center for Information Security (RCIS)1049215ldquoSide-channel Attack Standard
Evaluation Board (SASEBO)rdquordquo httpwwwrcisaistgojpspecialSASEBO
SASEBO-GII-jahtml
7 Z Chen S Morozov and P Schaumont ldquoA Hardware Interface for Hashing Algorithmsrdquo
Cryptology ePrint Archive Report 2008529 2008
8 ECRYPT II ldquoSHA-3 Hardware Implementationsrdquo httpehashiaiktugraz
atwikiSHA-3 Hardware Implementations
9 Y K Lee H Chan and I Verbauwhede ldquoIteration Bound Analysis and Throughput
Optimum Architecture of SHA-256 (384 512) for Hardware Implementationsrdquo
in In Information Security Appliciations 8th International Workshop WISA 2007
vol 4867 of LNCS pp 102-114 Springer 2007
33 33
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
Korex527 at gmailcom
Betelgs at cholcom
EYP_Z H^D Thank You
top related