[cryptography] Asynchronous forward secrecy encryption
natanael.l at gmail.com
Mon Sep 23 09:00:03 EDT 2013
I made a suggestion like this elsewhere:
Store the keys split up in several different files using Shamir's Secret
Sharing Scheme. Encrypt each file with a different key. Encrypt those keys
with a master key. XOR each encrypted key with the SHA256 of their
respective encrypted files. Put those XORed keys in the headers of their
If you manage to securely wipe just ~100 bits of any of the files, the keys
I don't know if that can provide enough assurance of secure deletion on a
flash memory, but it's better than nothing.
Den 23 sep 2013 14:40 skrev "Michael Rogers" <michael at briarproject.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 23/09/13 05:12, Dev Random wrote:
> > I've been thinking about this for a while now and I don't see a way
> > to do this with today's mobile devices without some external help.
> > The issue is that it's pretty much impossible to delete data
> > securely from a flash device. That means that in order to
> > guarantee PFS, you have to store the keys in memory only. But
> > again, in a mobile environment, you don't have access to stable
> > memory either, because of the OS restarting your app, or the device
> > itself rebooting.
> > Let's call this the persistence/deletion issue.
> Yes, this is a major issue with current mobile devices. As far as I'm
> aware, SSD commands like Trim and Secure Erase aren't available on SD
> cards or the built-in flash storage of mobile devices.
> Apple came within a whisker of solving the problem in iOS by creating
> an 'effaceable storage' area within the flash storage, which bypasses
> block remapping and can be deleted securely. However, iOS only uses
> the effaceable storage for resetting the entire device (by deleting
> the key that encrypts the user's filesystem), not for securely
> deleting individual files.
> A similar approach would be possible on Android, but I don't know of
> any Android devices with effaceable storage. The closest I've seen is
> hardware-backed key storage, where keys are generated, wrapped and
> deleted by a TPM-like chip. Software can use the TPM to perform
> operations using the wrapped keys but can't directly access them, and
> thus they can't be exported from the device without cracking open the
> TPM (physically or via a vulnerability).
> In combination with a hardware-based flash controller, this raises the
> bar for undeleting data pretty high: the adversary must compromise the
> flash controller to get access to data that's been logically but not
> physically deleted, then compromise the TPM to unwrap or undelete the
> deleted key with which the deleted data was encrypted.
> I'm not saying the bar is too high for a national security agency, but
> it's too high for some adversaries, so I believe it's worthwhile to
> think about forward secrecy on current mobile devices.
> > So, I submit that PFS in async messaging is impossible without help
> > from some kind of ephemeral, yet persistent storage. A possible
> > solution might be to store a portion of the key material (through
> > Shamir's secret sharing) on servers that you partially trust.
> Sounds like a great idea, especially in combination with a panic
> button or dead man's switch feature that alerts the servers to delete
> their shares.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----
> cryptography mailing list
> cryptography at randombit.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography