Updates to crypto_test app; STM32 crypto HW driver; CBC/CTR speed #2174
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
utzig
commented
Jan 31, 2020
utzig
commented
- apps: crypto_test: add benchmarks for CBC/CTR
- stm32: crypto: make driver obey syscfg HW support
- crypto: use 32-bit XOR in CBC/CTR
utzig
force-pushed
the
crypto-updates
branch
3 times, most recently
from
1ff621f
to
5a652be
Compare
|
Could someone take a look? |
kasjer
reviewed
Feb 25, 2020
| inbuf32 = (uint32_t *)inbuf8; | ||
| outbuf32 = (uint32_t *)outbuf8; | ||
| for (i = 0; i < len / 4; i++) { | ||
| outbuf32[i] = inbuf32[i] ^ _out32[i]; |
There was a problem hiding this comment.
I'm not sure what is the usage of this function but unaligned access here could crash Cortex-M0
There was a problem hiding this comment.
This should be fixed now, thanks!
| } | ||
| } | ||
| } | ||
| printf("done in %lu ticks\n", os_time_get() - t); |
There was a problem hiding this comment.
I would not use ticks to display time, you could not compare results of two different boards not knowing what tick mean on each one.
There was a problem hiding this comment.
Comparing to different boards is not relevant IMO, what is being done here is to compare the HW acceleration speed to SW implementations using tinycrypt/mbedTLS.
1) The table generation script was updated to save a block of CBC and CTR encrypted buffers (plus IV/NONCE). 2) Add new routines to run CBC/CTR and count cycles. Signed-off-by: Fabio Utzig <utzig@apache.org>
Allow disabling of HW support for CBC/CTR. This is a correctness change; nobody should do this in practice unless for testing the SW fallbacks or in the unlikely case that there is a BUG found in one of those encryption/decryption modes. Signed-off-by: Fabio Utzig <utzig@apache.org>
Using 32-bit XORs is around 10% faster with slightly increased code size (for optimized target). For CBC always requires AES block length buffers so just employ 32-bit XORs. For CTR due to the stream semantics, use 32-bit XOR when buffer is AES block length size, otherwise fallback to byte-by-byte XOR. Signed-off-by: Fabio Utzig <utzig@apache.org>
Style check summaryOur coding style is here!hw/drivers/crypto/src/crypto.c@@ -77,11 +77,11 @@
}
} else {
#endif
- for (i = 0; i < len; i++) {
- outbuf8[i] = inbuf8[i] ^ _out[i];
- }
-#if defined(__ARM_FEATURE_UNALIGNED)
- }
+ for (i = 0; i < len; i++) {
+ outbuf8[i] = inbuf8[i] ^ _out[i];
+ }
+#if defined(__ARM_FEATURE_UNALIGNED)
+ }
#endif
for (i = AES_BLOCK_LEN; i > 0; --i) { |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.