Skip to main content
deleted 110 characters in body
Source Link
Cookie04
  • 291
  • 2
  • 7

So I read this question about deniable encryption but it left me with a few questions. The first answer describes how you could hide one file system on a drive. The process goes like this:

  1. Fill the drive with random data
  2. Select a random offset and create the encrypted file system there so it's indistinguishable from the random data around it

Now my questions: How would one have multiple of these file systems (independent of another) in a structured way? If we select multiple random numbers for the offsets we might end up with one very large and one very small.

So I thought of a way to solve the first problem: You could divide the disk in equal blocks of say 1 GB to ensure that each block has the same size. Is there a better way?

Even if the ensure that each block has enough space for our purposes we still have the problem of needing to remember the offset and the password for that block. Is there any way to let the user only have to remember the password?

One solution I thought about was deriving the block number from the password, but if the user changes the password he would also have to move the data to that new block (kinda inefficent). Theres also the chance that the block derived from a password is already taken, so you can't use it (no go).

The only solution I found was trying the password on each block and checking for a magic number at the beginning to ensure correct decryption. This seems pretty inefficient though. Is there any other way while still preserving the deniable aspect of it?

The goal is to make it impossible for an attacker to know how much data there is on the disk.

So I read this question about deniable encryption but it left me with a few questions. The first answer describes how you could hide one file system on a drive. The process goes like this:

  1. Fill the drive with random data
  2. Select a random offset and create the encrypted file system there so it's indistinguishable from the random data around it

Now my questions: How would one have multiple of these file systems (independent of another) in a structured way? If we select multiple random numbers for the offsets we might end up with one very large and one very small.

So I thought of a way to solve the first problem: You could divide the disk in equal blocks of say 1 GB to ensure that each block has the same size. Is there a better way?

Even if the ensure that each block has enough space for our purposes we still have the problem of needing to remember the offset and the password for that block. Is there any way to let the user only have to remember the password?

One solution I thought about was deriving the block number from the password, but if the user changes the password he would also have to move the data to that new block (kinda inefficent). Theres also the chance that the block derived from a password is already taken, so you can't use it (no go).

The only solution I found was trying the password on each block and checking for a magic number at the beginning to ensure correct decryption. This seems pretty inefficient though. Is there any other way while still preserving the deniable aspect of it?

The goal is to make it impossible for an attacker to know how much data there is on the disk.

So I read this question about deniable encryption but it left me with a few questions. The first answer describes how you could hide one file system on a drive. The process goes like this:

  1. Fill the drive with random data
  2. Select a random offset and create the encrypted file system there so it's indistinguishable from the random data around it

Now my questions: How would one have multiple of these file systems (independent of another) in a structured way? If we select multiple random numbers for the offsets we might end up with one very large and one very small.

So I thought of a way to solve the first problem: You could divide the disk in equal blocks of say 1 GB to ensure that each block has the same size. Is there a better way?

Even if the ensure that each block has enough space for our purposes we still have the problem of needing to remember the offset and the password for that block. Is there any way to let the user only have to remember the password?

One solution I thought about was deriving the block number from the password, but if the user changes the password he would also have to move the data to that new block (kinda inefficent).

The only solution I found was trying the password on each block and checking for a magic number at the beginning to ensure correct decryption. This seems pretty inefficient though. Is there any other way while still preserving the deniable aspect of it?

The goal is to make it impossible for an attacker to know how much data there is on the disk.

clarified title and added "file-system" tag
Link
Cookie04
  • 291
  • 2
  • 7

Drive with deniable encryption and multiple independent file systems

Source Link
Cookie04
  • 291
  • 2
  • 7

Drive with deniable encryption

So I read this question about deniable encryption but it left me with a few questions. The first answer describes how you could hide one file system on a drive. The process goes like this:

  1. Fill the drive with random data
  2. Select a random offset and create the encrypted file system there so it's indistinguishable from the random data around it

Now my questions: How would one have multiple of these file systems (independent of another) in a structured way? If we select multiple random numbers for the offsets we might end up with one very large and one very small.

So I thought of a way to solve the first problem: You could divide the disk in equal blocks of say 1 GB to ensure that each block has the same size. Is there a better way?

Even if the ensure that each block has enough space for our purposes we still have the problem of needing to remember the offset and the password for that block. Is there any way to let the user only have to remember the password?

One solution I thought about was deriving the block number from the password, but if the user changes the password he would also have to move the data to that new block (kinda inefficent). Theres also the chance that the block derived from a password is already taken, so you can't use it (no go).

The only solution I found was trying the password on each block and checking for a magic number at the beginning to ensure correct decryption. This seems pretty inefficient though. Is there any other way while still preserving the deniable aspect of it?

The goal is to make it impossible for an attacker to know how much data there is on the disk.