Got a new Mac coming to replace my current one which has FileVault
turned on.

Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?

--
If you don't want to do something, one excuse is as good as another
- Yiddish proverb

In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
wrote:

> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

before will be much quicker since there's less to encrypt.

On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:

> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
> wrote:
>
>> Better/easier to FileVault the new machine before or after transferring
>> data to it via Migration Assistant?
>
> before will be much quicker since there's less to encrypt.

Why filevault it in the first place?

--
Tim

On 2021-12-11 09:04, TimS wrote:
> On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
>
>> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
>> wrote:
>>
>>> Better/easier to FileVault the new machine before or after transferring
>>> data to it via Migration Assistant?
>>
>> before will be much quicker since there's less to encrypt.
>
> Why filevault it in the first place?

Why _not_ filevault? It has a negligible effect on speed and means you
can dispose of the drive at end of life with no action other than
destroying the key.

--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens

On 2021-12-11 07:23, Wade Garrett wrote:
> Got a new Mac coming to replace my current one which has FileVault
> turned on.
>
> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

Just as easy before or after.
Better before as all stuff being on-boarded will be encrypted as it's
loaded.

I'd prefer the OS maintain a unique key for every file and when the file
is deleted (from the trash), destroy the key. Impossible to recover.
(akin to what iOS does).

--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens

In message <sp258j$9go$1@dont-email.me> Wade Garrett <Wade@cooler.net> wrote:
> Got a new Mac coming to replace my current one which has FileVault
> turned on.

> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

With a new mac it makes no difference at all; the FileVault process is
basically instantaneous.

--
First we must assume a spherical cow.

In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
> On 2021-12-11 09:04, TimS wrote:
>> On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
>>
>>> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
>>> wrote:
>>>
>>>> Better/easier to FileVault the new machine before or after transferring
>>>> data to it via Migration Assistant?
>>>
>>> before will be much quicker since there's less to encrypt.
>>
>> Why filevault it in the first place?

> Why _not_ filevault? It has a negligible effect on speed

Zero effect on speed with any T2 machine or M1 machine.

> and means you can dispose of the drive at end of life with no action
> other than destroying the key.

One of many advantages.

--
"Are you pondering what I'm pondering?"
"Well, I think so, Brain, but it's a miracle that this one grew
back."

On 2021-12-11 12:13, Lewis wrote:
> In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
>> On 2021-12-11 09:04, TimS wrote:
>>> On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
>>>
>>>> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
>>>> wrote:
>>>>
>>>>> Better/easier to FileVault the new machine before or after transferring
>>>>> data to it via Migration Assistant?
>>>>
>>>> before will be much quicker since there's less to encrypt.
>>>
>>> Why filevault it in the first place?
>
>> Why _not_ filevault? It has a negligible effect on speed
>
> Zero effect on speed with any T2 machine or M1 machine.

I'll test that next week with an external SSD.

--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens

In message <fF5tJ.23213$Pl1.18313@fx23.iad> Alan Browne <bitbucket@blackhole.com> wrote:
> On 2021-12-11 12:13, Lewis wrote:
>> In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
>>> On 2021-12-11 09:04, TimS wrote:
>>>> On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
>>>>
>>>>> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
>>>>> wrote:
>>>>>
>>>>>> Better/easier to FileVault the new machine before or after transferring
>>>>>> data to it via Migration Assistant?
>>>>>
>>>>> before will be much quicker since there's less to encrypt.
>>>>
>>>> Why filevault it in the first place?
>>
>>> Why _not_ filevault? It has a negligible effect on speed
>>
>> Zero effect on speed with any T2 machine or M1 machine.

> I'll test that next week with an external SSD.

Enabling file vault on external drives will still be slow. The instant
process on the T2 and M1 machines applies to the internal boot drive.

--
I WILL NOT DO THE DIRTY BIRD Bart chalkboard Ep. AABF08

On 2021-12-11 14:49, Lewis wrote:
> In message <fF5tJ.23213$Pl1.18313@fx23.iad> Alan Browne <bitbucket@blackhole.com> wrote:
>> On 2021-12-11 12:13, Lewis wrote:
>>> In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
>>>> On 2021-12-11 09:04, TimS wrote:
>>>>> On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
>>>>>
>>>>>> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
>>>>>> wrote:
>>>>>>
>>>>>>> Better/easier to FileVault the new machine before or after transferring
>>>>>>> data to it via Migration Assistant?
>>>>>>
>>>>>> before will be much quicker since there's less to encrypt.
>>>>>
>>>>> Why filevault it in the first place?
>>>
>>>> Why _not_ filevault? It has a negligible effect on speed
>>>
>>> Zero effect on speed with any T2 machine or M1 machine.
>
>> I'll test that next week with an external SSD.
>
> Enabling file vault on external drives will still be slow. The instant
> process on the T2 and M1 machines applies to the internal boot drive.

If that's the case then it's pretty much un-testable for speed even if I
start up that system with FV off:

"If FileVault isn’t enabled on a Mac with the T2 chip during the initial
Setup Assistant process, the volume is still encrypted, but the volume
key is protected only by the hardware UID in the Secure Enclave. If
FileVault is enabled later — a process that is immediate since the data
was already encrypted — an anti-replay mechanism prevents the old key
(based on hardware UID only) from being used to decrypt the volume. The
volume is then protected by a combination of the user password with the
hardware UID as previously described."

https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chip_Overview.pdf

I'll still do an external volume test - should still outpace the i7 iMac
on difference.
(https://groups.google.com/g/comp.sys.mac.system/c/1qSo1J4UqcM/m/RHonW9sjDQAJ
- about 11% slower to an encrypted external volume per my measurements
in 2016).

--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens

On 12/11/21 9:04 AM, TimS wrote:
> On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
>
>> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
>> wrote:
>>
>>> Better/easier to FileVault the new machine before or after transferring
>>> data to it via Migration Assistant?
>>
>> before will be much quicker since there's less to encrypt.
>
> Why filevault it in the first place?
>

S.E.C.U.R.I.T.Y.

In message <ed8tJ.22496$a24.15681@fx13.iad> Alan Browne <bitbucket@blackhole.com> wrote:
> On 2021-12-11 14:49, Lewis wrote:
>> In message <fF5tJ.23213$Pl1.18313@fx23.iad> Alan Browne <bitbucket@blackhole.com> wrote:
>>> On 2021-12-11 12:13, Lewis wrote:
>>>> In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
>>>>> On 2021-12-11 09:04, TimS wrote:
>>>>>> On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
>>>>>>
>>>>>>> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Better/easier to FileVault the new machine before or after transferring
>>>>>>>> data to it via Migration Assistant?
>>>>>>>
>>>>>>> before will be much quicker since there's less to encrypt.
>>>>>>
>>>>>> Why filevault it in the first place?
>>>>
>>>>> Why _not_ filevault? It has a negligible effect on speed
>>>>
>>>> Zero effect on speed with any T2 machine or M1 machine.
>>
>>> I'll test that next week with an external SSD.
>>
>> Enabling file vault on external drives will still be slow. The instant
>> process on the T2 and M1 machines applies to the internal boot drive.

> If that's the case then it's pretty much un-testable for speed even if I
> start up that system with FV off:

> "If FileVault isn’t enabled on a Mac with the T2 chip during the initial
> Setup Assistant process, the volume is still encrypted, but the volume
> key is protected only by the hardware UID in the Secure Enclave. If
> FileVault is enabled later — a process that is immediate since the data
> was already encrypted — an anti-replay mechanism prevents the old key
> (based on hardware UID only) from being used to decrypt the volume. The
> volume is then protected by a combination of the user password with the
> hardware UID as previously described."

> https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chip_Overview.pdf

Yes, I didn't recall the exact details because I just turn FileVault on
for all my machines.

> I'll still do an external volume test - should still outpace the i7 iMac
> on difference.

I would think so, I think the FileVault encryption is handled by the
neural engine.

--
Satan oscillate my metallic sonatas

On 2021-12-11 12:23:45 +0000, Wade Garrett said:
>
> Got a new Mac coming to replace my current one which has FileVault turned on.
>
> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

Migration Assistant is always best used when you are going through the
initial computer setting up process. Trying to do it afterwards can
cause issues with user ID conflicts.

In message <sp3f5u$hmt$1@gioia.aioe.org> Your Name <YourName@YourISP.com> wrote:
> On 2021-12-11 12:23:45 +0000, Wade Garrett said:
>>
>> Got a new Mac coming to replace my current one which has FileVault turned on.
>>
>> Better/easier to FileVault the new machine before or after transferring
>> data to it via Migration Assistant?

> Migration Assistant is always best used when you are going through the
> initial computer setting up process. Trying to do it afterwards can
> cause issues with user ID conflicts.

The question has nothing to do with Migration Assistant.

--
(on emojis) Remember when they added Groucho and no Harpo?

On 2021-12-11 19:14, Lewis wrote:
> In message <ed8tJ.22496$a24.15681@fx13.iad> Alan Browne <bitbucket@blackhole.com> wrote:

>> https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chip_Overview.pdf
>
> Yes, I didn't recall the exact details because I just turn FileVault on
> for all my machines.

Likewise, haven't really read up on it since FV changed to FV2. More
interested now as I'm planning the house conversion to Mx processors.
Work Macs will stay intel for quite a while (no urgent needs and some
legacy issues).

MBA allegedly arrives this week.

Can't wait for a "higher end" iMac (M1 Max perhaps - though the Pro is
probably more than enough for my needs). By spring maybe. I'd even
consider a Mini with high end Mx.

>> I'll still do an external volume test - should still outpace the i7 iMac
>> on difference.
>
> I would think so, I think the FileVault encryption is handled by the
> neural engine.

I wouldn't think so - AES is not all that complex to implement. Neural
engines are more for 'fuzzy stuff' (graphics, audio, etc.).

The M1 has the T2 functionality including the AES "inline" function for
system storage. But I wonder if it has a separate AES engine that can
be used generally (by any process) via the encryption libraries.

IAC, AES is not a very expensive function even in s/w. A requirement of
AES from the start). Below.

[1] https://www.oryx-embedded.com/doc/aes_8c_source.html

--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens

nospam <nospam@nospam.invalid> wrote:
> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
> wrote:

> > Better/easier to FileVault the new machine before or after transferring
> > data to it via Migration Assistant?

> before will be much quicker since there's less to encrypt.

Ditto. It's also good to test the drive out before dumping your datas
into it.
--
Incoming major (<2") winter rain storm 2 do more preparations 4 da warm nest & colony! Also, 2 many free weekend games again! :(
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

In message <nZOdnchZ77sSkCr8nZ2dnUU7-IednZ2d@earthlink.com> Ant <ant@zimage.comANT> wrote:
> nospam <nospam@nospam.invalid> wrote:
>> In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
>> wrote:

>> > Better/easier to FileVault the new machine before or after transferring
>> > data to it via Migration Assistant?

>> before will be much quicker since there's less to encrypt.

Still not correct.

> Ditto.

Nope.

> It's also good to test the drive out before dumping your datas into
> it.

If you have backups *you DO have backups?) then this is quite literally
a waste of time, and largely meaningless with modern drives that will
often simply report their internal status and not actually write
multiple terabytes of 0s to the drive.

--
Cecil is made of blood and unfinished leather

On 2021-12-11 07:23, Wade Garrett wrote:
> Got a new Mac coming to replace my current one which has FileVault
> turned on.
>
> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written
in place on SSD drives but written somewhere else and then the original
is deleted. But when it's deleted it is not erased (destroyed). So
until something overwrites those sectors (blocks on an SSD), the
information is recoverable.

Those blocks will get clobbered at some point, to be sure. This is not
acceptable for very secure requirements.

I've been searching through Apple docs and so far have found no mention
of this issue, so either it is handled and not mentioned, or it depends
on the blocks eventually being over-written. Apple are pretty
transparent with how they handle security and this I've yet to find.

Hope for the best. Plan for the worst. Encrypt on migration. Or fill
the rest of the drive with gibberish files and erase them after conversion.

Better: encrypt on migration.

(Ironically on spinning disk storage, write over in place is very
feasible; whereas on SSD it would be a desirable exception to wear
leveling strategies, but the logic of the storage device won't permit it).

--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens

In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne
<bitbucket@blackhole.com> wrote:

> Another reason to do it while migrating is an issue called Data
> Remanence. When an unencrypted file is encrypted it is not re-written
> in place on SSD drives but written somewhere else and then the original
> is deleted. But when it's deleted it is not erased (destroyed). So
> until something overwrites those sectors (blocks on an SSD), the
> information is recoverable.

only with substantial effort and expense.

> Those blocks will get clobbered at some point, to be sure. This is not
> acceptable for very secure requirements.
>
> I've been searching through Apple docs and so far have found no mention
> of this issue, so either it is handled and not mentioned, or it depends
> on the blocks eventually being over-written. Apple are pretty
> transparent with how they handle security and this I've yet to find.

that's a function of the ssd, not anything apple does.

it's also not possible to directly access the spare blocks, other than
via a forensic lab, i.e., substantial effort and expense.

> Hope for the best. Plan for the worst. Encrypt on migration. Or fill
> the rest of the drive with gibberish files and erase them after conversion.

filling the drive is unnecessary wear on an ssd and unless you're a
high profile target, overkill.

> Better: encrypt on migration.

yep.

> (Ironically on spinning disk storage, write over in place is very
> feasible; whereas on SSD it would be a desirable exception to wear
> leveling strategies, but the logic of the storage device won't permit it).

hard drives remap bad blocks and their contents remain.

whether it's still readable depends on how bad the block actually is.

On 2021-12-13 17:17, nospam wrote:
> In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne
> <bitbucket@blackhole.com> wrote:
>
>> Another reason to do it while migrating is an issue called Data
>> Remanence. When an unencrypted file is encrypted it is not re-written
>> in place on SSD drives but written somewhere else and then the original
>> is deleted. But when it's deleted it is not erased (destroyed). So
>> until something overwrites those sectors (blocks on an SSD), the
>> information is recoverable.
>
> only with substantial effort and expense.
>
>> Those blocks will get clobbered at some point, to be sure. This is not
>> acceptable for very secure requirements.
>>
>> I've been searching through Apple docs and so far have found no mention
>> of this issue, so either it is handled and not mentioned, or it depends
>> on the blocks eventually being over-written. Apple are pretty
>> transparent with how they handle security and this I've yet to find.
>
> that's a function of the ssd, not anything apple does.

Apple are mute on the issue.

>
> it's also not possible to directly access the spare blocks, other than
> via a forensic lab, i.e., substantial effort and expense.

Due to TRIM perhaps, yes.

>> Hope for the best. Plan for the worst. Encrypt on migration. Or fill
>> the rest of the drive with gibberish files and erase them after conversion.
>
> filling the drive is unnecessary wear on an ssd and unless you're a
> high profile target, overkill.

1 overwrite. The method is for the paranoid and won't affect the long
term by any serious amount.

>> Better: encrypt on migration.
>
> yep.
>
>> (Ironically on spinning disk storage, write over in place is very
>> feasible; whereas on SSD it would be a desirable exception to wear
>> leveling strategies, but the logic of the storage device won't permit it).
>
> hard drives remap bad blocks and their contents remain.

Hardly relevant as bad blocks don't come into being very often ...

--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens

On Monday, December 13, 2021 at 3:48:36 PM UTC-7, Alan Browne wrote:
> On 2021-12-13 17:17, nospam wrote:
> > In article <5JOtJ.122411$SW5....@fx45.iad>, Alan Browne
> > <bitb...@blackhole.com> wrote:
> >
> >> Another reason to do it while migrating is an issue called Data
> >> Remanence. When an unencrypted file is encrypted it is not re-written
> >> in place on SSD drives but written somewhere else and then the original
> >> is deleted. But when it's deleted it is not erased (destroyed). So
> >> until something overwrites those sectors (blocks on an SSD), the
> >> information is recoverable.
> >
> > only with substantial effort and expense.
> >
> >> Those blocks will get clobbered at some point, to be sure. This is not
> >> acceptable for very secure requirements.
> >>
> >> I've been searching through Apple docs and so far have found no mention
> >> of this issue, so either it is handled and not mentioned, or it depends
> >> on the blocks eventually being over-written. Apple are pretty
> >> transparent with how they handle security and this I've yet to find.
> >
> > that's a function of the ssd, not anything apple does.
> Apple are mute on the issue.
> >
> > it's also not possible to directly access the spare blocks, other than
> > via a forensic lab, i.e., substantial effort and expense.
> Due to TRIM perhaps, yes.
> >> Hope for the best. Plan for the worst. Encrypt on migration. Or fill
> >> the rest of the drive with gibberish files and erase them after conversion.
> >
> > filling the drive is unnecessary wear on an ssd and unless you're a
> > high profile target, overkill.
> 1 overwrite. The method is for the paranoid and won't affect the long
> term by any serious amount.
> >> Better: encrypt on migration.
> >
> > yep.
> >
> >> (Ironically on spinning disk storage, write over in place is very
> >> feasible; whereas on SSD it would be a desirable exception to wear
> >> leveling strategies, but the logic of the storage device won't permit it).
> >
> > hard drives remap bad blocks and their contents remain.
> Hardly relevant as bad blocks don't come into being very often ...
> --
> "...there are many humorous things in this world; among them the white
> man's notion that he is less savage than the other savages."
> -Samuel Clemens

He is a jerk; advocates have kf'd his flooding. What he really can not make
is a bot that keeps switching names, then flood posts have a shot at being
one quarter as idiotic as he is. When will Ixchel support the allegation
he's made multiple times about me being a Ryan Sullivan sock? The guy is
as loved as a wet dog at a parlor social -- and with good reason. It's his
problem but he does not care. Obviously he would rather blame Ryan Sullivan
than face reality. The bulk of the regulars in this group do customizations
either as a pastime or as a career, so I have doubts anyone here thinks
of automation to be "black magic".

What is your evidence?

--
One Smart Penny!!
https://swisscows.com/web?query=%22narcissistic%20bigot%22
Automate Google Groups https://groups.google.com/forum/#!search/PetruzzellisorCarroll
https://www.perkinscoie.com/en/professionals/michael-glaser.html
Steve 'Narcissistic Bigot' Carroll

In article <35QtJ.55547$Gco3.25300@fx01.iad>, Alan Browne
<bitbucket@blackhole.com> wrote:

> >> Those blocks will get clobbered at some point, to be sure. This is not
> >> acceptable for very secure requirements.
> >>
> >> I've been searching through Apple docs and so far have found no mention
> >> of this issue, so either it is handled and not mentioned, or it depends
> >> on the blocks eventually being over-written. Apple are pretty
> >> transparent with how they handle security and this I've yet to find.
> >
> > that's a function of the ssd, not anything apple does.
>
> Apple are mute on the issue.

there's nothing for apple to say. it's how ssds work.

> > it's also not possible to directly access the spare blocks, other than
> > via a forensic lab, i.e., substantial effort and expense.
>
> Due to TRIM perhaps, yes.

not just that.

directly accessing raw blocks requires bypassing the controller
firmware, which is not something end users are able to do.

a data recovery lab, such as drivesavers, can do that, and it isn't
going to be particularly cheap.

> >> Hope for the best. Plan for the worst. Encrypt on migration. Or fill
> >> the rest of the drive with gibberish files and erase them after conversion.
> >
> > filling the drive is unnecessary wear on an ssd and unless you're a
> > high profile target, overkill.
>
> 1 overwrite. The method is for the paranoid and won't affect the long
> term by any serious amount.

it's 1 more than is needed and doesn't actually help.

unless you're a high profile target, nobody is going to bother trying
to recover your ssd since it's not worth the effort.

if someone was able to access some of the spare blocks, they'd only get
fragments of files. the chances that there's something of interest in a
random block of a random file is statistically quite low.

> >> (Ironically on spinning disk storage, write over in place is very
> >> feasible; whereas on SSD it would be a desirable exception to wear
> >> leveling strategies, but the logic of the storage device won't permit it).
> >
> > hard drives remap bad blocks and their contents remain.
>
> Hardly relevant as bad blocks don't come into being very often ...

nor do those who want to forensically examine hard drives...

the point is that unencrypted data can also exist on a hard drive.

In message <5JOtJ.122411$SW5.45782@fx45.iad> Alan Browne <bitbucket@blackhole.com> wrote:
> On 2021-12-11 07:23, Wade Garrett wrote:
>> Got a new Mac coming to replace my current one which has FileVault
>> turned on.
>>
>> Better/easier to FileVault the new machine before or after transferring
>> data to it via Migration Assistant?

> Another reason to do it while migrating is an issue called Data
> Remanence. When an unencrypted file is encrypted

This is not an issue on new Macs, the data is ALWAYS encrypted, it is
just a matter of if the key to the encryption is private or not.

--
Silence is golden, duct tape is silver.

In message <131220211717401043%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
> In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne
> <bitbucket@blackhole.com> wrote:

>> Another reason to do it while migrating is an issue called Data
>> Remanence. When an unencrypted file is encrypted it is not re-written
>> in place on SSD drives but written somewhere else and then the original
>> is deleted. But when it's deleted it is not erased (destroyed). So
>> until something overwrites those sectors (blocks on an SSD), the
>> information is recoverable.

> only with substantial effort and expense.

It also really is not. The idea you can reassemble a file by gathering
random cells on an SSD is pretty much the definition of impossible.

>> Better: encrypt on migration.

> yep.

Not on a recent Mac, it makes absolutely no difference.

--
The brain is an amazing organ, it works every second of every day
from before we're even born right up until the instant we fall in
love.

On 2021-12-13 21:36, Lewis wrote:
> In message <131220211717401043%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
>> In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne
>> <bitbucket@blackhole.com> wrote:
>
>>> Another reason to do it while migrating is an issue called Data
>>> Remanence. When an unencrypted file is encrypted it is not re-written
>>> in place on SSD drives but written somewhere else and then the original
>>> is deleted. But when it's deleted it is not erased (destroyed). So
>>> until something overwrites those sectors (blocks on an SSD), the
>>> information is recoverable.
>
>> only with substantial effort and expense.
>
> It also really is not. The idea you can reassemble a file by gathering
> random cells on an SSD is pretty much the definition of impossible.
>
>>> Better: encrypt on migration.
>
>> yep.
>
> Not on a recent Mac, it makes absolutely no difference.

For a "drive recovery" (Drive removed from computer) that is correct.

But, if your laptop is stolen[1] and booted into Recovery Mode and
Target Disk Mode is used on the attack-Mac, then it would be as
transparent as a window without Filevault requiring the password...

https://blog.kolide.com/modern-macs-still-need-filevault-d5e2f55c083b
.... skip about 1/4 of the way down.

--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens