Anelok: first try at crypto: for further study (4/3)
werner at almesberger.net
Sun Apr 19 14:10:05 UTC 2015
My last few mails may have made the topic of cryptography in Anelok
look trivial and boring. But don't worry, there is more:
- structuring of information: I already mentioned one aspect in the
second mail: there may be one block of key data for each account
record or multiple records could share a block. What makes the most
There are also other issues, like how we represent directories and
different access levels.
- what part of the account information should be encrypted and what
not ? Encrypting everything may be the safest choice, but are there
major drawbacks ? Does computational overhead go through the roof ?
- management of the list of authorized readers and writers. How does
a device learn about changes in the list ? How are the changes
validated ? And how many such lists are there anyway - just one per
user (shared and synchronized among all the user's devices) or
- what algorithms to use ? I'm pretty much set on Curve25519  for
ECDH, but what for symmetric encryption, what for hashing, what
key derivation function ? We'd also want algorithms that are
reasonably compatible in what data they expect and produce, and
how they stretch or lose entropy.
- last but not least, what implementations ? There are quite a lot of
implementations for ECDH alone [2, 3, 4, 5, 6, 7] (and that's just
the smaller packages) and there are more when we consider ECDSA as
well [8, 9]. The last two are from , which is about combining
Curve25519 and Ed25519 - there may be more packages that do only
So, there's still a bit of work to do. I think I'll aim for having a
rough structure that has all the major components needed for
read-only operation, then make a "compiler" that converts a textual
account database into the corresponding encrypted format.
As a first step, it may even make sense to just use crypto_box from
NaCl . While it has some properties that make it a poor fit for
what we need (e.g., it doesn't support multiple readers and it also
expects to hold the entire message in memory, which is something we
may prefer not to do, given the MCU's limited RAM), it contains all
the building blocks we need and does at least as much work as Anelok
is expected to do. This makes it a good placeholder for the "real"
system, with a similar code size and run time footprint.
That should provide enough hands-on experience to plan where to go
next, and it should also exercise the main algorithms, so that we can
have an idea of how good Anelok's MCU is at doing these things.
 DJB's original, optimized for x86:
 NaCl: a bundle containing Curve25519 and other good stuff:
 Do you like Twitter ?
 uNaCl, when small MCUs (*) are your thing:
 Specifically, Curve25519 optimized for Cortex M0:
 Donna, Curve25519 in portable C:
 Curve25519 to Ed25519:
 And vice versa:
(*) I'm always happy to I see that some library exists in an AVR
variant. Then I can be pretty sure my little Cortex won't be
overwhelmed by it either.
More information about the discussion