1. The things we're really trying to protect - contact identities,
message contents, etc - can't be erased from memory because they're
encapsulated inside objects we don't control.

2. Long-term secrets can't be protected by erasing them from memory
because they're stored in the database and the database key has to be
held in memory whenever the app's running.

3. If the runtime uses a compacting garbage collector then we have no
way to ensure an object is erased from memory.

4. Trying to erase secrets from memory makes the code more complex.

Conclusion: Let's not try to protect secrets from an attacker who can
read arbitrary memory locations.

Private messages are now the same as group messages, but groups can be
private or public. When a contact is added, a private group is created
and designated as the inbox for exchanging private messages with the
contact.

Android doesn't currently store bundles persistently, so it's premature
to protect against accidental information leaks through persistent
bundle storage. Protecting against deliberate information leaks by the
OS is probably futile, so there's currently no need for bundle
encryption.

The invitation and private messaging UIs are currently broken. Some key
rotation bugs were fixed; others may have been created (unit tests
needed). An encoding for private keys was added. Pseudonyms were moved
out of the messaging package and ratings were moved in.

Only the bundle contents created by Briar classes are encrypted.

This should make it possible to develop the core in Eclipse without the ADT.

This makes us Suite B compliant and saves 32 bytes per frame. The
AES/GCM implementation refuses to decrypt the frame header before
checking the MAC, so we have to use AES/CTR to peek at the header. The
header is still covered by the MAC, and we still check it after peeking!

CryptoComponentImpl needs some unit tests.

consequent distinction between segments and frames.

Each connection's keys are derived from a secret that is erased after
deriving the keys and the secret for the next connection.

predefined tags in the protocol and serial components, and "IV" for
the encrypted IVs used to identify connections in the transport
component.

authenticate each frame before parsing its contents. Each connection
starts with a tag, followed by any number of frames, each starting
with the frame number (32 bits) and payload length (16 bits), and
ending with a MAC (256 bits).

Tags have the following format: 32 bits reserved, 16 bits for the
transport ID, 32 bits for the connection number, 32 bits (set to zero
in the tag) for the frame number, and 16 bits (set to zero in the tag)
for the block number. The tag is encrypted with the tag key in
ECB mode.

Frame numbers for each connection must start from zero and must be
contiguous and strictly increasing. Each frame is encrypted with the
frame key in CTR mode, using the plaintext tag with the appropriate
frame number to initialise the counter.

The maximum frame size is 64 KiB, including header and footer. The
maximum amount of data that can be sent over a connection is 2^32
frames - roughly 2^48 bytes, or 8 terabytes, with the maximum frame
size of 64 KiB. If that isn't sufficient we can add another 16 bits to
the frame counter.