Re: EFS - Why decryption necessary when copying file?
From: Alan Cobb (alanREMOVE@THISalancobb.com)
Date: 01/14/03
- Next message: x y: "Re: User account encryption"
- Previous message: null: "Re: User account encryption"
- In reply to: Roger Abell [MVP]: "Re: EFS - Why decryption necessary when copying file?"
- Next in thread: Gary: "Re: EFS - Why decryption necessary when copying file?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Alan Cobb <alanREMOVE@THISalancobb.com> Date: Tue, 14 Jan 2003 10:40:47 -0800
On Tue, 14 Jan 2003 07:19:48 -0700, "Roger Abell [MVP]"
<mvpNOSPAM@asu.edu> wrote:
Thanks for the details Roger.
Alan Cobb
>"Alan Cobb" <alanREMOVE@THISalancobb.com> wrote in message
>news:7ej72vg3p628rttu9srsc164qjb7c0178s@4ax.com...
>> Hi Roger,
>>
>Hi Alan
>
>> Thanks for the explanation. Which leads to a couple
>> more questions :).
>>
>> >Also, when copying, unless the target directory is marked
>> >as encrypted, how would one indicate whether the result
>> >is to be in the clear or encrypted ?
>>
>> But doesn't the same situation occur when I copy an
>> encrypted file to an unencrypted directory on the local
>> machine?
>Sure it does, as I understand things, but they may have
>put in optimiziation code to check and see if the target
>will end up encrypted and if so do a more direct copy,
>but I doubt this has been done.
>EFS (as well as compression) is tied in very low.
>In its (EFS's) original release (IIRC late 3.51 age) the old
>(and now scarce
>http://www.amazon.com/exec/obidos/tg/stores/offering/list/-/155615660X/all/r
>ef=sr_pb_a/002-3218428-8576016 )
>NTFS book by Helen Custer (David Cuttler's wife) described
>the encrypt/decrypt as a 64KB blocked algorithm that takes
>place right down at the ntdisk level (just before the raw
>write/read) in a highly optimized way.
>
>> In that case the encrypted file stays encrypted
>> (still green) even though nothing else in the directory is.
>Sure, but do you not expect to see it end up encrypted ?
>Now, how it got that way is something you have assumed
>is by a direct image transfer. I do not know for sure, but
>have expressed an opinion of my expectation as to how.
>
>Maybe an MS person will clarify the internals of this for us.
>
>> After I saw that I expected the same behavior when copying
>> to another machine's shared drive.
>>
>Reasonable if you overlook the issues due to a machine boundary.
>
>> >If you think of how the file is accessed, and where EFS
>> >sits in the chain of things, the act of reading the file will
>> >result in the file passing through decryption. A copy
>> >operation is a read followed by a write. So in order to
>> >implement encrypted-copy, how this chain is set up would
>> >need to be redefined. I guess the question was how often
>> >such an encrypted-copy would be of use, how expensive it
>> >would be to change the chain of implementation compared
>> >to how expensive to just do the decrypt and reencrypt when
>> >copying to a local encrypted directory, and how troublesome
>> >to use the ntbackup method when moving the file as-is is
>> >actually desired.
>>
>> Interesting. So I guess ntbackup, given its special
>> knowledge of the OS and EFS is able to use some alternate
>> method of reading the files that bypasses decryption
>> when it is doing its backup? Just curious.
>>
>NTbackup uses some APIs provided for backup / restore
>applications. With XP these now even include the volume
>shadow copy capability to deal with "in-use" situations
>that can lead to "out-of-sync" problems between files and
>file list in other "copy all" methods.
>
>> Thanks,
>> Alan Cobb
>
- Next message: x y: "Re: User account encryption"
- Previous message: null: "Re: User account encryption"
- In reply to: Roger Abell [MVP]: "Re: EFS - Why decryption necessary when copying file?"
- Next in thread: Gary: "Re: EFS - Why decryption necessary when copying file?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
