Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #223973 > unrolled thread

Advice on encrypted filesystem

Started byrhkramer@gmail.com
First post2020-06-25 03:30 +0200
Last post2020-06-27 23:30 +0200
Articles 7 on this page of 27 — 11 participants

Back to article view | Back to linux.debian.user

Contents

  Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-25 03:30 +0200
    Re: Advice on encrypted filesystem Roberto C. Sánchez <roberto@debian.org> - 2020-06-25 03:40 +0200
      Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-25 04:20 +0200
      Re: Advice on encrypted filesystem john doe <johndoe65534@mail.com> - 2020-06-25 09:50 +0200
      Re: Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-25 13:40 +0200
        Re: Advice on encrypted filesystem David <bouncingcats@gmail.com> - 2020-06-25 15:30 +0200
          Re: Advice on encrypted filesystem Nicolas George <george@nsup.org> - 2020-06-25 15:40 +0200
            Sound in Jitsi/BBB [was: dvice on encrypted filesystem] <tomas@tuxteam.de> - 2020-06-25 16:00 +0200
              Re: Sound in Jitsi/BBB [was: dvice on encrypted filesystem] Nicolas George <george@nsup.org> - 2020-06-25 16:00 +0200
                Re: Sound in Jitsi/BBB [was: dvice on encrypted filesystem] <tomas@tuxteam.de> - 2020-06-25 16:10 +0200
          Zoom client for Linux (was: Re: Advice on encrypted filesystem) rhkramer@gmail.com - 2020-06-25 16:20 +0200
        Re: Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-25 16:30 +0200
    Re: Advice on encrypted filesystem David Wright <deblis@lionunicorn.co.uk> - 2020-06-25 04:30 +0200
      Re: Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-25 13:50 +0200
        Re: Advice on encrypted filesystem David Wright <deblis@lionunicorn.co.uk> - 2020-06-26 15:30 +0200
          Re: Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-26 16:40 +0200
          Re: Advice on encrypted filesystem Michael Stone <mstone@debian.org> - 2020-06-26 17:50 +0200
            Re: Advice on encrypted filesystem David Wright <deblis@lionunicorn.co.uk> - 2020-06-26 21:10 +0200
              Re: Advice on encrypted filesystem Michael Stone <mstone@debian.org> - 2020-06-26 21:50 +0200
                Re: Advice on encrypted filesystem David Wright <deblis@lionunicorn.co.uk> - 2020-06-27 03:30 +0200
                  Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 06:10 +0200
                    Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 09:10 +0200
                    Re: Advice on encrypted filesystem Admin4 <admin4@dwaves.de> - 2020-06-27 10:10 +0200
                      Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 21:50 +0200
                        Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 22:20 +0200
                  Re: Advice on encrypted filesystem Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-27 10:50 +0200
                    Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 23:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#224084

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2020-06-27 06:10 +0200
Message-ID<Amak9-6px-1@gated-at.bofh.it>
In reply to#224077
On 2020-06-26 18:25, David Wright wrote:

> There's still the problem of what one does about sensitive data if
> one has been rash enough to write it unencrypted onto an SSD. Would
> shred -n 1   be preferable? Not really, because that doesn't hit the
> ex-file areas. What then?

The best option is to command the SSD firmware to do a "secure delete". 
Some SSD manufacturers provide utilities for doing this.  Alternatively, 
it can be done from the command line with Linux.


David

[toc] | [prev] | [next] | [standalone]

#224089

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2020-06-27 09:10 +0200
Message-ID<Amd8l-88C-3@gated-at.bofh.it>
In reply to#224084
On 2020-06-26 21:00, David Christensen wrote:
> On 2020-06-26 18:25, David Wright wrote:
> 
>> There's still the problem of what one does about sensitive data if
>> one has been rash enough to write it unencrypted onto an SSD. Would
>> shred -n 1   be preferable? Not really, because that doesn't hit the
>> ex-file areas. What then?
> 
> The best option is to command the SSD firmware to do a "secure delete". 
> Some SSD manufacturers provide utilities for doing this.  Alternatively, 
> it can be done from the command line with Linux.

Correction "ATA Secure Erase command":

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase


David

[toc] | [prev] | [next] | [standalone]

#224091

FromAdmin4 <admin4@dwaves.de>
Date2020-06-27 10:10 +0200
Message-ID<Ame4q-ft-1@gated-at.bofh.it>
In reply to#224084
1) backup your data to external usb drive

2) reinstall with encrypted enabled

3) restore data

= a lot of unencrypted data get's overwritten (if user does not have a
lot of data, generate some X-D)

On 6/27/20 6:00 AM, David Christensen wrote:
> On 2020-06-26 18:25, David Wright wrote:
>
>> There's still the problem of what one does about sensitive data if
>> one has been rash enough to write it unencrypted onto an SSD. Would
>> shred -n 1   be preferable? Not really, because that doesn't hit the
>> ex-file areas. What then?
>
> The best option is to command the SSD firmware to do a "secure
> delete". Some SSD manufacturers provide utilities for doing this. 
> Alternatively, it can be done from the command line with Linux.
>
>
> David

[toc] | [prev] | [next] | [standalone]

#224120

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2020-06-27 21:50 +0200
Message-ID<AmoZP-6EP-7@gated-at.bofh.it>
In reply to#224091
> On 6/27/20 6:00 AM, David Christensen wrote:
>> On 2020-06-26 18:25, David Wright wrote:
>>
>>> There's still the problem of what one does about sensitive data if
>>> one has been rash enough to write it unencrypted onto an SSD. Would
>>> shred -n 1   be preferable? Not really, because that doesn't hit the
>>> ex-file areas. What then?
>>
>> The best option is to command the SSD firmware to do a "secure
>> delete". Some SSD manufacturers provide utilities for doing this.
>> Alternatively, it can be done from the command line with Linux.


On 2020-06-27 01:05, Admin4 wrote:
 > 1) backup your data to external usb drive
 >
 > 2) reinstall with encrypted enabled
 >
 > 3) restore data

That process is likely to leave both host-accessible and hidden 
unencrypted blocks from the prior installation on the device.


 > = a lot of unencrypted data get's overwritten (if user does not have a
 > lot of data, generate some X-D)

"a lot" is not the same as "all".  The ATA secure erase command is 
designed to erase all blocks, both host-accessible and hidden.


David

[toc] | [prev] | [next] | [standalone]

#224123

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2020-06-27 22:20 +0200
Message-ID<AmpsR-74E-5@gated-at.bofh.it>
In reply to#224120
On 2020-06-27 12:47, David Christensen wrote:

> The ATA secure erase command is 
> designed to erase all blocks, both host-accessible and hidden.

STFW, "secure erase" (aka "security erase") is an older feature and may 
not erase all NAND blocks, just the "mapping table".  (When I have done 
this on my Intel SSD 520 Series devices and then dumped the entire drive 
with hexdump(1), the host reported all zeroes.  But, I have not 
disassembled a drive, removed the NAND chips, and put them into a NAND 
chip reader.)


There is a newer feature "sanitize' that is supposed to erase both the 
mapping table and all data storage NAND blocks:

https://www.micron.com/about/blog/2017/march/how-to-securely-erase-micron-sata-ssds

https://www.diskpart.com/articles/sanitize-or-secure-erase-ssd-4125.html

https://www.microcontrollertips.com/ssds-secure-erase-sanitize-faq/


David

[toc] | [prev] | [next] | [standalone]

#224093

FromAndrei POPESCU <andreimpopescu@gmail.com>
Date2020-06-27 10:50 +0200
Message-ID<AmeH7-sp-1@gated-at.bofh.it>
In reply to#224077

[Multipart message — attachments visible in raw view] — view raw

On Vi, 26 iun 20, 20:25:32, David Wright wrote:
> 
> Ironically, 2048 is neither cargo cult nor magic, but *is* the default
> used by LUKS when the kernel does not supply one, as documented two
> paragraphs earlier. Are you suggesting a 1MB alignment might be
> insufficient? If one were to specify NxMB, LUKS will still use 1MB
> (again as documented).

The latest recommendation I saw for "cheap flash based" storage is 4MiB 
in order to align with erase block sizes, so now I'm starting all my 
partitions at 4MiB instead of 1MiB.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#224124

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2020-06-27 23:30 +0200
Message-ID<AmqyB-7HH-3@gated-at.bofh.it>
In reply to#224093
On 2020-06-27 01:46, Andrei POPESCU wrote:

> The latest recommendation I saw for "cheap flash based" storage is 4MiB
> in order to align with erase block sizes, so now I'm starting all my
> partitions at 4MiB instead of 1MiB.


Interesting subject -- thanks for bringing it up.  :-)


STFW there does not appear to be a "one size fits all" solution -- the 
"best" answer depends upon the specific storage device/ controller/ 
firmware version and specific OS/ kernel/ version.


Given my solid-state system drives are 16+ GB, losing 3 MiB by aligning 
the partitions at 4 MiB boundaries instead of 1 MiB boundaries is a 
small sacrifice; just in case it really does matter (now or in the future).


David

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web