cryptsetup.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Wiping disk vs. initializing container
@ 2023-06-06 21:08 bugcounterism
  2023-06-07  3:30 ` Arno Wagner
  0 siblings, 1 reply; 5+ messages in thread
From: bugcounterism @ 2023-06-06 21:08 UTC (permalink / raw)
  To: cryptsetup

Hi there,

does overwriting an entire hard disk with random data before setting up
encryption make initializing a LUKS container (as described in section
5.3 of the FAQ) obsolete?


Thanks
Michael


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Wiping disk vs. initializing container
  2023-06-06 21:08 Wiping disk vs. initializing container bugcounterism
@ 2023-06-07  3:30 ` Arno Wagner
  2023-06-07 10:03   ` bugcounterism
  0 siblings, 1 reply; 5+ messages in thread
From: Arno Wagner @ 2023-06-07  3:30 UTC (permalink / raw)
  To: cryptsetup; +Cc: bugcounterism

If it is crypto-grade randomness, yes.
But note that Section 5.3 may still be faster.

Regards,
Arno


On Tue, Jun 06, 2023 at 23:08:50 CEST, bugcounterism@malbolge.net wrote:
> Hi there,
> 
> does overwriting an entire hard disk with random data before setting up
> encryption make initializing a LUKS container (as described in section
> 5.3 of the FAQ) obsolete?
> 
> 
> Thanks
> Michael
> 

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Wiping disk vs. initializing container
  2023-06-07  3:30 ` Arno Wagner
@ 2023-06-07 10:03   ` bugcounterism
  2023-06-07 11:09     ` Michael Kjörling
  0 siblings, 1 reply; 5+ messages in thread
From: bugcounterism @ 2023-06-07 10:03 UTC (permalink / raw)
  To: cryptsetup; +Cc: Arno Wagner, Arno Wagner

Am Wed, 7 Jun 2023 05:30:38 +0200
schrieb Arno Wagner <wagner@arnowagner.info>:

> If it is crypto-grade randomness, yes.
> But note that Section 5.3 may still be faster.

I see.

Now I have some follow-up questions:

1. Would `cat /dev/urandom > /dev/sdX` give me crypto-grade randomness?

2. Is initializing a LUKS container with zeroes equivalent to filling a
   whole drive with crypto-grade random data if the LUKS container
   spans the whole disk?

3. The FAQ says:

     If the target was in use previously, it is a good idea to wipe it
     before creating the LUKS container in order to remove any trace of
     old file systems and data.

   So, isn't just filling the whole disk with random data before setting
   up the LUKS container the simplest solution if you want to a) destroy
   old data reliably, b) put the disk into a clean state, and c) make
   sure that parts of the LUKS container that have not been written to
   cannot be distinguished from those that have?

4. Should new hard disks that have not been used previously also be
   filled with random data in order to achieve c)?


Thanks
Michael


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Wiping disk vs. initializing container
  2023-06-07 10:03   ` bugcounterism
@ 2023-06-07 11:09     ` Michael Kjörling
  2023-06-07 19:23       ` Arno Wagner
  0 siblings, 1 reply; 5+ messages in thread
From: Michael Kjörling @ 2023-06-07 11:09 UTC (permalink / raw)
  To: cryptsetup

On 7 Jun 2023 12:03 +0200, from bugcounterism@malbolge.net:
> 1. Would `cat /dev/urandom > /dev/sdX` give me crypto-grade randomness?

With a modern kernel, it should, yes.

Or you could set up a temporary mapping with a throwaway key and write
from /dev/zero through that. The result should be much the same but my
experience is that the latter is more performant.


> 2. Is initializing a LUKS container with zeroes equivalent to filling a
>    whole drive with crypto-grade random data if the LUKS container
>    spans the whole disk?

It should be. If not, that would be a more general vulnerability.


> 3. The FAQ says:
> 
>      If the target was in use previously, it is a good idea to wipe it
>      before creating the LUKS container in order to remove any trace of
>      old file systems and data.
> 
>    So, isn't just filling the whole disk with random data before setting
>    up the LUKS container the simplest solution if you want to a) destroy
>    old data reliably, b) put the disk into a clean state, and c) make
>    sure that parts of the LUKS container that have not been written to
>    cannot be distinguished from those that have?

Generally, absent the key, ciphertext should be indistinguishable from
random data. So for an adversary who does not have access to the key,
the disk having been filled with random data (e.g. cat from
/dev/urandom) or a container having been filled with predictable data
(e.g. cat from /dev/zero) should be largely equivalent.

Also, any random data should be as good as any other random data, so
there would be no easy way to tell whether a particular chunk of
random data is there because of an initial overwrite with random data,
or because of useful data being stored through the later-created LUKS
container.


> 4. Should new hard disks that have not been used previously also be
>    filled with random data in order to achieve c)?

I would argue that it should, and by extension also for another
reason: allocation patterns can provide very strong clues both about
the amount of data stored, and the type of file system within the
container. A NTFS file system looks very different in terms of
allocation patterns from an ext4 or Btrfs or exfat file system.

SSDs introduce other factors, particularly relating to wear leveling,
where a different trade-off might be reasonable.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Wiping disk vs. initializing container
  2023-06-07 11:09     ` Michael Kjörling
@ 2023-06-07 19:23       ` Arno Wagner
  0 siblings, 0 replies; 5+ messages in thread
From: Arno Wagner @ 2023-06-07 19:23 UTC (permalink / raw)
  To: cryptsetup

On Wed, Jun 07, 2023 at 13:09:11 CEST, Michael Kjörling wrote:
> On 7 Jun 2023 12:03 +0200, from bugcounterism@malbolge.net:
> > 2. Is initializing a LUKS container with zeroes equivalent to filling a
> >    whole drive with crypto-grade random data if the LUKS container
> >    spans the whole disk?
> 
> It should be. If not, that would be a more general vulnerability.

Except for the header. There may be some space in the header or
between header and data that does not get written this way.
Hence I think I recommend using plain dm-crypt for a cyptsetup
based wipe. The header and empty space is not a concern for
data-patterns leaking from the container though. It is just a
concern for removing old data.

> > 3. The FAQ says:
> > 
> >      If the target was in use previously, it is a good idea to wipe it
> >      before creating the LUKS container in order to remove any trace of
> >      old file systems and data.
> > 
> >    So, isn't just filling the whole disk with random data before setting
> >    up the LUKS container the simplest solution if you want to a) destroy
> >    old data reliably, b) put the disk into a clean state, and c) make
> >    sure that parts of the LUKS container that have not been written to
> >    cannot be distinguished from those that have?
> 
> Generally, absent the key, ciphertext should be indistinguishable from
> random data. So for an adversary who does not have access to the key,
> the disk having been filled with random data (e.g. cat from
> /dev/urandom) or a container having been filled with predictable data
> (e.g. cat from /dev/zero) should be largely equivalent.

It is. Anything else would allow you to break the cipher used.
 
> Also, any random data should be as good as any other random data, so
> there would be no easy way to tell whether a particular chunk of
> random data is there because of an initial overwrite with random data,
> or because of useful data being stored through the later-created LUKS
> container.

That depends. Good quality non-crypto random data often allows you 
to determine the generator state and may even have blatantly obvious
patterns. For example, I remember one generator that just toggled
the smallest bit in the output stream. In that case, you can still 
determine what was written within the container later, because the
ovwerwrite randomness has those patterns while the encrypted data
does not.

> > 4. Should new hard disks that have not been used previously also be
> >    filled with random data in order to achieve c)?
> 
> I would argue that it should, and by extension also for another
> reason: allocation patterns can provide very strong clues both about
> the amount of data stored, and the type of file system within the
> container. A NTFS file system looks very different in terms of
> allocation patterns from an ext4 or Btrfs or exfat file system.

You put in the random data to reduce data leaking from 
the encrypted container. A new disk should hence be treated the
same.
 
> SSDs introduce other factors, particularly relating to wear leveling,
> where a different trade-off might be reasonable.

I would recommend to do it for SSDs also, just be aware it is not 
as good as for spinning disks. Still should help. Maybe do several
random overwrites with SSD. Usually you have a few hundred before
the disks becomes worn out.

Arno 

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-06-07 19:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-06 21:08 Wiping disk vs. initializing container bugcounterism
2023-06-07  3:30 ` Arno Wagner
2023-06-07 10:03   ` bugcounterism
2023-06-07 11:09     ` Michael Kjörling
2023-06-07 19:23       ` Arno Wagner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).