- Nov 01, 2016
-
-
Torsten Grote authored
-
- Feb 11, 2016
-
-
akwizgran authored
-
- Feb 10, 2016
-
-
akwizgran authored
-
- Jan 27, 2016
-
-
akwizgran authored
-
- Dec 14, 2015
-
-
akwizgran authored
-
- Dec 08, 2015
-
-
akwizgran authored
-
- Nov 30, 2015
-
-
akwizgran authored
-
- Dec 29, 2014
-
-
akwizgran authored
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.
-
- Dec 14, 2014
-
-
akwizgran authored
-
- Nov 06, 2014
-
-
akwizgran authored
-
- Oct 08, 2014
-
-
akwizgran authored
-
- Oct 03, 2014
-
-
akwizgran authored
-
- Jan 24, 2014
-
-
akwizgran authored
-
- Jan 08, 2014
- May 14, 2013
-
-
akwizgran authored
To fix issue #3611966, KeyManagerImpl's handling of TransportAddedEvent was made asynchronous. This made it possible for a thread to call KeyManager.endpointAdded() before the KeyManager had asynchronously handled the TransportAddedEvent from a previous call to DatabaseComponent.addTransport().
-
- Apr 11, 2013
-
-
akwizgran authored
Find the newest dead secret for each endpoint, erase any others and derive from the newest.
-
- Apr 10, 2013
- Apr 05, 2013
-
-
akwizgran authored
-