Werner Almesberger | 24 May 02:00 2015

Anelok: a dummy case for AAA (2/2)

This all looks nice so far. However, the path to get there turned out
to be a lot stonier than I had expected. The problem is that my mill
is acting up badly along the Z axis, reducing the depth by up to
almost half of what the CAD model says.

Here is an example. This is what the slices look like in FreeCAD:


And this is what came out:


The nominal thickness of 17.5 mm yielded pieces between 9.3 and 10.3 mm.
The jump from ~10 to ~9 mm may have been caused by setting the depth of
the bottom such that the mill would cut well below the floor of the upper
MDF block. By the way, double-sided adhesive tape and MDF form an
amazingly strong bond, making it quite an effort to pick the slices from
the block after milling.

The depths of the cut-outs for screw heads are even more puzzling:

Nominal		Measured	Factor
--------------- --------------- ---------------
 5 mm		3.7-4.0 mm	74-80%
 8 mm		 5.0 mm		63%
10 mm		5.6-6.3 mm	56-63%

Just weird.

(Continue reading)

Werner Almesberger | 24 May 01:39 2015

Anelok: a dummy case for AAA (1/2)

I decided to give the YZ slices a try, to find out what the new form
factor would feel like. This is my mill, after making a mess:


This is what it produced, with the sawdust shaken off, not sanded:


After a bit of sanding, the slices already looked a lot more civilized:


These are the pieces I made:


The big hole is for the battery, the small holes are for 1/8" screws.
Some of the pieces on the left side also have larger partial holes
for the screw head or a nut. That way, I can use the screws I have at
home, which would be a bit too short to span the entire width. And it's
also neater if no parts of the screws protrude.

Here is a size check of the assembled package:


This is what it looks like compared to the CR2032 case design:

(Continue reading)

Werner Almesberger | 18 May 20:59 2015

Anelok: exploring the deep end

TL;DR: boost converter happy with AAA-type input, after all

A while ago, I tested how Anelok behaved at low batter voltages:

The result was that it did reasonably well at anything we could expect
from a CR2032 cell, but would become unstable at 1.4 V, which is
uncomfortably close to the best-case voltage an AAA cell would provide.

I couldn't quite explain why this was so, given that the boost
converter is specified for operation with a battery voltage as low as
0.8 V.

While I lay sleepless last night, it finally hit me: it's Q1 again !

Let's look at
to see what's going on:

The battery voltage is applied before Q1. The purpose of Q1 is to
disconnect the battery if USB provides power. Q1 is a FET with a gate
threshold voltage of about 1.0 V. If the battery voltage is at or below
that gate threshold voltage, the FET will not conduct at all. If the
battery voltage is only a little higher, it will conduct, but

According to the data sheet [1], we need at least 1.2 V before it will
admit the sort of current the boost converter needs at such a voltage.
Worse, at that point it still has a resistance of > 1 Ohm, so we will
need an even higher voltage before things can work.
(Continue reading)

Werner Almesberger | 30 Apr 00:20 2015

Anelok: saving more power (2/2)

This is the current consumption for an entire usage session:


Please note that the y axis (current) uses logarithmic scale. For
clarity, I'll write power management states in upper case.

We begin with the power off. Then the lab power supply is turned on and
provides a constant 2.4 V. First, the boot loader runs. Current
consumption is high while in the boot loader because I haven't taught
it any power-saving tricks yet.

Then the Anelok application goes through its initialization procedure
and at about 6.9 seconds, it enters STANDBY (more about this later),
from which I awaken it at around 9.2 s.

Anelok then activates all its subsystems (ACTIVE), briefly displays the
banner, and then proceeds to the login dialog. There I enter the usual
"V".  One can see the brief spikes of activity when I enter one more
position. Also, since the number of active pixels increases with the
number of positions, the overall current slowly increases.

At about 15.2 s I finish logging in and Anelok begins decrypting the
account database. First it calculates the shared key, then it decrypts
the content of records as it draws the account selection list. All this
takes about 2 seconds and Anelok draws 22 mA.

The last state of the login screen is shown through all this. If using
a more optimize implementation of the key agreement won't significantly
reduce the run time, it would make sense to clear the screen to lower
(Continue reading)

Werner Almesberger | 29 Apr 19:28 2015

Anelok: saving more power (1/2)

Revisiting the "empty" battery

First an update on how deeply Anelok discharged its battery during
the first "solo" run, about a month ago:

I put it to the usual discharge test, discharging into a 15 kOhm
resistor. This is the result:


For comparison, this is the result of the original test from February
and March, with a new battery:


Both batteries were 7 years old Sony cells, so one can compare the
results directly. The initially new battery crashed through 2.4 V
after about 1030 hours, while the one that had spent a productive if
short life in Anelok reached that point after about 500 hours.

So this means that Anelok could use more than half of the battery's
energy content. And that's still before optimizing any capacitors.


So far, so good. But it's still not nice that Anelok is merrily
suckling 0.7 mA (board #2) to 0.9 mA (board #1) from the battery
while doing absolutely nothing useful. 
(Continue reading)

Werner Almesberger | 28 Apr 18:59 2015

Anelok: using NaCl

I implemented a first proof of concept prototype of encryption, based
on NaCl's crypto_box [1] using the TweetNaCl implementation [2].

The this proof-of-concept is quite crude: there is only one reader,
keys and encrypted data and kept in memory forever, the account
database is linked into the code, and the only way to create or edit
accounts is by running a scary collection of programs on the Linux

Code size

Nevertheless, this exercises more than half of the crypto system and
provides a realistic workload. Code size comparison:

	   text    data     bss     dec     hex filename
Base	  24676    1416    4200   30292    7654 anelok-2014.elf
Dynamic	  25484    1200    4200   30884    78a4 anelok-2014.elf
Decrypt	  29180    1200    4200   34580    8714 anelok-2014.elf

"Base" is the version before all the crypto work, where the account
database was not encrypted and just hard-coded.

"Dynamic" changes various APIs to work with account information that
is not available at build time. As a consequence of one of the API
changes, the account database could now be "const" and thus moved
from "data" to "text".

"Decrypt" then adds TweetNaCl and decryption. The code size increase
is quite moderate, which means that we still have a lot of room for
(Continue reading)

Werner Almesberger | 19 Apr 16:10 2015

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

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
(Continue reading)

Mark Tuson | 19 Apr 11:24 2015

Why I joined: the NanoNote


I've been a member of this list for something like five years; I joined 
following my purchase of a Ben NanoNote, thinking it might he useful to 
be a member of the community. Help and be helped, and all that.

There was supposed to be a successor to the Ben about three years ago, 
and there wasn't. In fact, the second successor should have been 
released last year, and it wasn't.

So, I ask, was the whole NanoNote thing a flash-in-the-pan episode of 
wishful thinking? Or was it a real project that simply fizzled out? Last 
time I asked about it I was told something like 'they tried and you're 
evil for not appreciating the effort that's gone into this,' but that's 
not really a helpful answer. What actually happened? Is there a point in 
me still waiting on this mailing list to see if anyone's going to pull 
their finger out and make the damned thing, or what?

The actual reason why I'm writing to you like this is that since the 
project fizzled out to nothing, I've been a member of this list, waiting 
to see what was going to happen, and in the meantime I've been 
constantly bombarded with emails from the list, talking about projects I 
don't care two sugarlumps about.

Eagerly awaiting a real response.

Mark Tuson, BSc.

Werner Almesberger | 19 Apr 06:19 2015

Anelok: first try at crypto: randomness (3/3)

Now we get to the fun part: randomness.

Entropy users

An obvious place where Anelok requires randomness is for the generation
of record keys.

We may also want to provide an initialization vector (IV [1]) for the
payload encryption, but I haven't worked out an attack scenario yet
where not having an IV would significantly help the attacker to
accomplish anything meaningful. Suggestions ?

Note that the IV doesn't necessarily require randomness. Maybe we could
generate it deterministically from, say, the encrypted keys. This may
be somewhat similar to what NaCl's crypto_box [2] does with the help of
a nonce [3] (haven't looked at the details yet).

Last but not least, public keys used by devices (i.e., readers and
writers) require an excellent entropy source.

Anelok also needs random numbers for a few other things, but these are
not directly related to the encryption of account records.

Random number generation

The problem with randomness is that it is an expensive good, especially
in small embedded systems like Anelok. And it is also a fragile thing.
Therefore, we should try to use randomness as sparingly and efficiently
(Continue reading)

Werner Almesberger | 19 Apr 00:40 2015

Anelok: first try at crypto: something-nymity (2/3)

Sometimes, one may want a bit more privacy. Let's see what options we
have for this.


One possible feature that occurred to me is to hide the information of
who has written a record from anyone who is not an authorized reader.
This could be accomplished by introducing an "author" who is the real
source of the information in the record, and letting the "writer" just
be a pseudonym.

This pseudonym could be a completely random private key (*) used only
once, or anything more durable than that.

(*) For Curve25519, all it takes to build a valid private key from a
    random bit string is to clear or set five bits at fixed locations.
    ("Computing secret keys" in [1].)

The only changes needed in the system would be:

- we replace the checksum with a cryptographic signature [2, 3], which
  certifies that the writer did indeed what the author intended it to

- for identification, include the author's public key in the encrypted

- make the reader look up the author's public key in the list of
  authorized writers and validate the signed hash after decrypting.
(Continue reading)

Werner Almesberger | 18 Apr 17:56 2015

Anelok: first try at crypto: overview (1/3)

I thought a bit more about the details of encrypting the account
database. This is a first attempt at defining the general structure of
the cryptosystem:


Some optional features are drawn in grey. I'll discuss them towards
the end of this mail. The whole drawing is a little complex, sorry
about that. For a more gentle introduction, I'll have to break it down
into smaller pieces.

What this shows is the process of encrypting and decrypting a record
of the account database. The record would contain the password and may
contain other things, e.g., the name of the account record (e.g., "My
server"), maybe some URL or address, a user or login name, etc.

This information is encrypted such that all the authorized readers
(i.e., Anelok devices and any other trusted systems) can read it. For
simplicity, I assume for now that we have a trusted source for the
public keys of the authorized readers (and only of readers who are
authorized). This source is shown as the "Authorized" box.


When creating a new account record or when editing an existing record,
the writer first prepares the record's content ("Plaintext"), adds a
checksum ("MIC", Message Integrity Code), then generates a key
("Record key") and uses this key to encrypt plaintext and checksum
with the symmetric cipher "Esym."
(Continue reading)