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
This is because Vista uses EFS and BitLocker. XP just uses EFS.
BitLocker encrypts all data on a system volume to prevent unauthorized users from successfully booting the PC with a different operating system or swapping the drive to a different computer to read the data. BitLocker is included with the Enterprise and Ultimate editions of Windows Vista.
what does that have to do with EFS compat?
Oh, that's terrific guys! I'm glad that Vista warned me about this change, so that I was able to back up the new key that I apparently needed when it changed my files behind my back!
Seriously, I was so happy when I could no longer access any of my encrypted files even after dutifully importing the (old) backed-up encryption key. Maybe someday MS will learn to stop changing things without telling people (cf. silent Windows updates).
can u tell us more about your situation.. from reading your mail it doesnt sound like you should lose access to your data.
My data was encrypted in XP; its certificate was backed up. I had to reinstall XP several times throughout my use of it, but never had any trouble; I would just restore the backed up key, take ownership, and everything would be fine.
I upgraded to Vista; I reinstalled Vista, imported my previously functional encryption key, but still cannot access my data. Evidently this is because my data was re-encrypted with a new key of which I was unaware?
I would have thought this issue would have been given more coverage on the internet... Surely I'm not the only person who wants to dual boot XP and Vista while accessing EFS encrypted files with both OSes?
Anyway don't know if you've seen this before mate, but it might provide a bit more info:
Too bad they say nothing about a fix!
download link for bitlocketogo ....
nevermind....this doesn't work for the problem
I realize MArks post is 3+ years old, but I wanted to make sure everyone was aware that the link he references DOES provide a fix:
"To resolve this issue, install Windows Vista Service Pack 1 (SP1). For more information, click the following article number to view the article in the Microsoft Knowledge Base: "
935791 (support.microsoft.com/.../935791 ) How to obtain the latest Windows Vista service pack