HKDF: Implement on tinydtls as well #95
Closed
Conversation
This file contains hidden or 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
Given that AES-CCM comes in various shapes and sizes, the function may still need renaming (not sure whether it makes sense to have it parametrized like AES-GCM), but the constants should be good.
... fixing failure to build with strict RIOT configurations. Checking for <0 before casting to unsigned ensures that all cases are covered; the compiler is invited to do any further optimization.
In scenarios where no signature algorithms are present (like when using only a backend that can do AEAD), this prevents "unused parameter" compiler errors.
Following the precendent in suit.c that already uses that condition.
Along with its Makefile, tinydtls also needs a minimal configuration header as it might be output by a configure script (but its complexity is low enough that a static file does just as well for our purposes, and is much less of a hassle). For AES-CCM, a single encrypt-decrypt test is run, based on the Packet Vector 1 of <https://www.rfc-editor.org/rfc/rfc3610.html#section-8>.
Since the silkeh/clang images use Debian buster now, libgcc-6-dev is not available any more; replacing with the latest that is.
Clang is a bit stricter when it comes to static arrays with the size of
a static const, replacing with defined expressions.
The removed allowed compiler warnings were only relevant to the older
released versions of tinydtls ("master") branch, which was never used in
a committed version of this port -- but the new ones are required for
Clang and do not disturb GCC operation.
The compatibility API's behavior changed in eclipse-tinydtls/tinydtls#34; this picks the parameters that work for AES-CCM-16-64-128.
in analogy to cose_crypto_is_aead
There is no need for a selector on this branch, but one is coming up.
Contributor
Author
|
I think that with the additions that are now in already (AES-CCM through tinycrypt in #103, HKDF from #94), and given how much headache tinyDTLS has caused me (I don't have concrete points, only vague memories of their master branch being old and develop moving erratically, plus lots of workarounds in libCOSE), it's best to close this one unfinished. The cryptographic operations I need are in, and I see no need to add an extra backend just because. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This is extending #94 based on the tinydtls addition of #91.
It's as WIP as #94, and once #91 is merged, it makes sense to concentrate the efforts here: With two implementations it's clearer how HKDF can be built on either library's KDF.