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

Werner Almesberger werner at
Sat Apr 18 15:56:37 UTC 2015

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."

The writer then has to attach the record key to the record in a way
that lets the readers retrieve it. It does this by performing
Diffie-Hellman key agreement (ECDH [1]) using its own private key and
each reader's public key. ECDH provides us with a shared secret for
writer and reader. We then mix the bits in this secret with a key
derivation function ("KDF" [2]), use it to encrypt the record key for
the respective reader, and add this encrypted key to the record
("Alice EK", etc.)

To allow the reader to find its encrypted key, we use the reader's
public key as identifier and add it as well ("Alice PK").

This is done for every authorized reader. The encryption algorithm
("Esym" again) may or may not be identical to the one we used for the
actual content of the record.

Last but not least, we also store the public key of the writer in the
record, because the readers will need (*) it to compute their shared
secret. The little "P2P" boxes translate a private key to the
corresponding public key.

(*) We'll revisit this in the following mail.


To decrypt an account record, the reader performs the ECDH key
agreement using its own private key and the writer's public key.
Then, after applying the KDF, we decrypt the encrypted record key with
it, using the decryption function of the symmetric cipher ("Dsym").

The reader selects which encrypted key (e.g., "Alice EK") to use by
searching for an entry with its public key in the list of public key
and encrypted key pairs.

Once we have the record key, we can decrypt the record (the second
"Dsym") and verify the checksum. Checking the integrity can be
important if an incorrect password could produce a denial of service
situation worse than merely not being able to retrieve the password,
e.g., when an ATM eats the credit card after three failed attempts.

So far, this is all nice and easy. Now, can we make it more
interesting ? Yes, of course we can !


I already mentioned denial of service. Now, it would be easy for some
malevolent person with access to our encrypted record to just create a
fake record with incorrect information, encrypt it with their own
public key (we assume that the public keys of readers are generally
known), and then add their own key as the writer's public key to the

If we assume that we also have access to a trusted list of writers
(which may just be the same as our list of authorized readers), we can
whether a record's writer really is authorized simply by looking up
("Find") the public key in the list.

If it's not there, the record is bogus. And if it's there, and someone
else has written the record, it should fail the integrity check.

I'm not sure yet whether something as simple as, say, a CRC would be
sufficient for this, or whether we need a cryptographic hash function
[3] to make sure the integrity check is not easily fooled.

Next mail: anonymity, or something like that.

- Werner


More information about the discussion mailing list