search

nthdimtech / signet-client

Client code for Signet and Signet HC
https://www.nthdimtech.com/signet
GNU General Public License v3.0
20 stars 8 forks source link

Encrypt complete storage space for more privacy/plausible deniability #51

Open greenhelper opened 6 years ago

greenhelper commented 6 years ago

Right now an external viewer can inspect a backup file and estimate (roughly?) how many entries the Signet is holding.

Wouldn’t it be nice to get some plausible deniability in the sense that no one without the proper passphrase can see how much the signet is used? Without the passphrase the 192 KB file would be just filled with random data, no structure should be visible (and especially no “FF FF FF” values as it is right now)

Ideally, the same would be done on the signet device itself but I am not sure how feasible that is (hw/processor needs to be strong enough I guess) so that when a device is lost the finder cannot extract anything at all from it except random data.

nthdimtech commented 6 years ago

I like the idea. It's hard to quickly generate that much random data using my current methods. The microcontroller RNG can generate random data at a high speed but I don't trust it's properties so I supplement it with a clock noise signal source with a very low generation speed.

I think what I want to do is to have blank spaces filled with random data in a background process (on the device). It could fill the blank spaces in a semi random fashion so even if the background filling was not complete it would not be easy to differentiate random filling with real entries.

On 02/20/2018 05:25 PM, greenhelper wrote:

Right now an external viewer can inspect a backup file and estimate (roughly?) how many entries the Signet is holding.

Wouldn’t it be nice to get some plausible deniability in the sense that no one without the proper passphrase can see how much the signet is used? Without the passphrase the 192 KB file would be just filled with random data, no structure should be visible (and especially no “FF FF FF” characters as it is right now)

Ideally, the same would be done on the signet device itself but I am not sure how feasible that is (hw/processor needs to be strong enough I guess) so that when a device is lost the finder cannot extract anything at all from it except random data.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nthdimtech/signet-desktop-client/issues/51, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad4tAK54CrPiSm0C7rGWoOFNUJoIwZQyks5tW3CDgaJpZM4SM8Bu.

greenhelper commented 6 years ago

Glad you can see where I am coming from!

It would be a cool first step if at least the backups could be encrypted so that an outside observer who comes across the backup files cannot easily determine how much has changed between backups!

Edit: I know, I can do this myself now with PGP etc. but it's an additional step I have to do whenever I backup!

nthdimtech commented 6 years ago

I have considered this risk as well. I think it might be good enough to reencrypt each backup with a second round of AES-256 CBC where the block chaining crossed flash memory blocks and a key wrapping scheme was used similar to that on the device but using a different inner key for every backup.

I'm not going to get to this right away as I am busy with the Android client but I will make a series of security related features afterwards.