Difference between revisions of "Projects:2020s1-1210 Performance Evaluation of Cryptographic Functions"
(→Performance Metrics) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 34: | Line 34: | ||
== Results == | == Results == | ||
===Performance Metrics=== | ===Performance Metrics=== | ||
| + | [[File:Implementation Performance Comparison.JPG|thumb|Performance Comparison results measuring the number of cycles required as overhead and average cycles per block for each encryption operation]] | ||
| + | |||
Results were collected using a range of different cipher modes from AES. Both accelerated implementations generally saw large performance increases compared to the software implementation, with hybrid outperforming hardware in most cases. | Results were collected using a range of different cipher modes from AES. Both accelerated implementations generally saw large performance increases compared to the software implementation, with hybrid outperforming hardware in most cases. | ||
| − | + | A fascinating exception to this trend is when the GCM cipher mode is used. In this mode the hybrid implementation shows almost no improvement over software, however the hardware implementation completes the operation in 1/1000th of the time as it can execute the operation in parallel. GCM is likely to run faster on the software and hybrid implementations when a different algorithm for calculating the GHASH value required, however will not catch up to the hardware implementation speed greatly unless hardware acceleration for the calculation of the GHASH value is provided. | |
| − | |||
| − | A fascinating exception to this trend is when the GCM cipher mode is used. In this mode the hybrid implementation shows almost no improvement over software, however the hardware implementation completes the operation in 1/1000th of the time as it can execute the operation in parallel. | ||
[[File:GCM Implementation Results.JPG|thumb|Results from GCM mode showed a remarkable performance advantage favouring the Hardware Implementation]] | [[File:GCM Implementation Results.JPG|thumb|Results from GCM mode showed a remarkable performance advantage favouring the Hardware Implementation]] | ||
| Line 48: | Line 48: | ||
* The result of the hybrid implementation outperforming the hardware implementation is unexpected. | * The result of the hybrid implementation outperforming the hardware implementation is unexpected. | ||
* This is likely due to the hardware overhead running on the processor rather than an external memory controller. | * This is likely due to the hardware overhead running on the processor rather than an external memory controller. | ||
| − | * The hybrid implementation is superior for small scale tasks, but the hardware implementation will outperform in tasks that are | + | * The hybrid implementation is superior for small scale tasks, but the hardware implementation will outperform in tasks that are parallelised. |
| + | * The hardware implementation is likely to run faster than the hybrid implementation for larger test cases when a direct memory access controller is available. | ||
Latest revision as of 16:04, 16 October 2020
Contents
Introduction
With the advent of an increasingly online and interconnected world, the need for fast and efficient data encryption has never been higher. In pursuit of this, the Australian Semiconductor Technology Company (ASTC) has sponsored this project to examine three kinds of implementations of cryptographic operations in a RISC-V based embedded system. The objective is to compare and evaluate the performance of software based, hardware based, and hybrid implementations of AES utilizing a dedicated co-processor supplied by ASTC.
Project Team
Project Students
- Lewis Omond
- Kieran Hunt
Project Supervisors
- Braden Phillips (The University of Adelaide)
- Peter Ashenden (ASTC)
Background
Encryption is a security measure that underpins private communication of data between devices on the internet. The Advanced Encryption Standard (AES) defines the algorithm used to encrypt data before it is sent. As a company developing processors for use in Internet of Things devices, the Australian Semiconductor Technology Company (ASTC) is interested in the performance of their designs when used for encryption tasks. To this end, ASTC have requested an investigation into processor performance when conducting encryption operations with varying degrees of hardware acceleration.
Aims & Objectives
- Produce three different implementations of AES on ASTC’s RV32IC_P5 RISC_V processor with varying levels of hardware acceleration.
- Provide analysis regarding the relative performance of each implementation in terms of cost and performance.
Implementation Platforms
All implementations of AES were tested on the RV32IC_P5, running on an Arty A7 100T FPGA Development Board.
The FPGA development board used to implement all tests.
Software Implementation: The software implementation used the base RV32IC_P5 with no additional hardware acceleration.
Hybrid Implementation: For the hybrid implementation, ASTC added additional instructions to the base processor micro-architecture.
Hardware Implementation: The Hardware Implementation utilised an external accelerator module designed by ASTC to handle all encryption operations.
Results
Performance Metrics
Results were collected using a range of different cipher modes from AES. Both accelerated implementations generally saw large performance increases compared to the software implementation, with hybrid outperforming hardware in most cases.
A fascinating exception to this trend is when the GCM cipher mode is used. In this mode the hybrid implementation shows almost no improvement over software, however the hardware implementation completes the operation in 1/1000th of the time as it can execute the operation in parallel. GCM is likely to run faster on the software and hybrid implementations when a different algorithm for calculating the GHASH value required, however will not catch up to the hardware implementation speed greatly unless hardware acceleration for the calculation of the GHASH value is provided.
Cost Metrics
It was also observed that the hardware implementation has the largest FPGA utilisation, with software being the smallest and hybrid the median. Conversely the hardware implementation has the smallest code size, with software being the largest, and hybrid again the median. Memory utilisation was relatively consistent between implementations.
Conclusions
- The result of the hybrid implementation outperforming the hardware implementation is unexpected.
- This is likely due to the hardware overhead running on the processor rather than an external memory controller.
- The hybrid implementation is superior for small scale tasks, but the hardware implementation will outperform in tasks that are parallelised.
- The hardware implementation is likely to run faster than the hybrid implementation for larger test cases when a direct memory access controller is available.
