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 ECDSA. 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 [1] http://cr.yp.to/ecdh.html [2] DJB's original, optimized for x86: wget http://cr.yp.to/ecdh/curve25519-20050915.tar.gz [3] NaCl: a bundle containing Curve25519 and other good stuff: http://nacl.cr.yp.to/features.html [4] Do you like Twitter ? http://tweetnacl.cr.yp.to/ [5] uNaCl, when small MCUs (*) are your thing: http://munacl.cryptojedi.org/ [6] Specifically, Curve25519 optimized for Cortex M0: http://munacl.cryptojedi.org/curve25519-cortexm0.shtml [7] Donna, Curve25519 in portable C: https://code.google.com/p/curve25519-donna/ [8] Curve25519 to Ed25519: https://github.com/trevp/ref10_extract [9] And vice versa: https://github.com/orlp/ed25519 [10] http://crypto.stackexchange.com/questions/13077/can-curve25519-keys-be-used-with-ed25519-keys (*) 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. _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
