Anelok: first try at crypto: for further study (4/3)

Werner Almesberger werner at
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
  sense ?

  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
  multiple ?

- what algorithms to use ? I'm pretty much set on Curve25519 [1] 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 [10], 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 [3]. 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.

- Werner

[2] DJB's original, optimized for x86:
[3] NaCl: a bundle containing Curve25519 and other good stuff:
[4] Do you like Twitter ?
[5] uNaCl, when small MCUs (*) are your thing:
[6] Specifically, Curve25519 optimized for Cortex M0:
[7] Donna, Curve25519 in portable C:
[8] Curve25519 to Ed25519:
[9] 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 mailing list