I just wanted to make sure folks realized that Vista and XP EFS files aren't exactly compatible...
Here was a snip from a recent question:
" I’m asking this question on behalf of another colleague. He’s having problems accessing encrypted files on a removable HDD in XP. He encrypted the folder and files in Vista and backed up the certificate. Now he’s attached the HDD to an XP machine and copied the certificate over but he can’t access the encrypted files and folders. When he tried it on another Vista machine, he can access it. Is there a difference in the EFS structure in Vista and XP that’s preventing this?"
They both use AES256 but in the Vista case the $EFS stream has changed and is not supported on downlevel OS's...
See http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsck_efs_duwf.mspx?mfr=true for more info on the internals for EFS.
Creating a New File with Encryption Enabled
There are two ways to create a file that has encryption already enabled. One method is to use Windows Explorer to create a file inside an encrypted folder. For example, in Windows Explorer, you can click an encrypted folder and then, on the File menu, point to New , and then click Rich Text Document . A second method is available to applications when they call the CreateFile() API with the file encryption flag, FILE_ATTRIBUTE_ENCRYPTED. Depending on which way you do it, NTFS checks the encryption status of the parent folder or of the flag passed in. If NTFS finds that the file must be created as encrypted, it calls the EFS FSRTL, which requests the EFS service to generate the metadata (FEK, DDF, and DRF) for the file object. The EFS service acquires the metadata from CryptoAPI and returns it by means of the EFS FSRTL to the EFS driver.
When the EFS service returns the metadata, the EFS driver sets up an EFS context for the file object and creates a $EFS stream of data containing the metadata. As the user writes data in the file, NTFS calls the FSRTL to encrypt the data.
Encrypting an Existing Plaintext File
Changing a file from plaintext to encrypted (by selecting the Encrypt contents check box in the Advanced Attributes dialog box) calls EncryptFile(). This API creates a backup copy of the file and requests the FEK, DRF, and DDF from the EFS service. The API then passes this metadata to the FSRTL by way of NTFS. The FSRTL sets up an EFS context for the file object and creates a $EFS stream with DDF, DRF, and so forth, for that object. EncryptFile() then reads the data from the backup and writes the data to the file. During the write, NTFS calls the FSRTL to encrypt the data before writing. When the writing is complete, the backup file is automatically deleted.
How Data Is Read and Written in Encrypted Files
Users do not need to decrypt files or folders during normal operations because EFS provides transparent encryption and decryption during data writes and reads. When you open the encrypted file, your private key (from your protected store in your user profile) is applied to the DDF to unlock the FEK, and the file contents appear on-screen in plaintext. EFS automatically detects an encrypted file and locates a user certificate and associated private key in the certificate and key stores.
Opening an encrypted file calls CreateFile(). NTFS checks the file on the disk to determine its encryption status, then calls the EFS service to verify the user. The EFS service finds the user's certificate and private key, and requests CryptoAPI to use the private key to decrypt the FEK. The EFS service then returns the FEK by way of the FSRTL to the EFS driver. If the user password or recovery agent information has changed, the EFS service requests a new DDF or DRF from CryptoAPI, as required, and returns it with the FEK to replace the old metadata.
When the EFS service returns the metadata, the EFS driver sets up an EFS context for the file object and creates a $EFS stream containing the metadata. The FEK decrypts the file so that it appears in plaintext on the screen.
As the user writes data in the file, NTFS calls the EFS FSRTL to encrypt the data.
If another user tries to open the file, access is denied. No one else can decrypt the file without the encryptor's private key or a private key for recovery. This is true even if administrators change permissions or file attributes, or file ownership is shared.
PS - looks like this may be fixed in Vista SP1 ....
[update april2 2008] guess not -- see http://support.microsoft.com/kb/939391