Implementation is based on the BLAKE2b implementation from BouncyCastle, and is
therefore licensed under the BouncyCastle license (which will make future
upstreaming of the code easier).
Use XSalsa20-Poly1305 instead of AES-GCM for transport encryption and password storage.
This patch integrates @str4d's new authenticated cipher implementation. It depends on !18.
See merge request !35
Switch KDF from SHA-256 to Blake2. #169
The BTP spec calls for Blake2s, but there's no Java implementation available. I suggest we go with Blake2b for now. If it turns out to be a performance bottleneck on 32-bit platforms we can consider implementing Blake2s and merging it upstream.
This depends on !13.
See merge request !21
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.
This can be used to combine e.g. the platform's SecureRandom
implementation with our own, so that a weakness in either source doesn't
harm security as long as the other source is strong.
Note that this is only the generator part of Fortuna, not the
accumulator. The generator requires a seed, which is provided by a
platform-specific implementation of SeedProvider. On Linux the
implementation reads the seed from /dev/urandom.
