NogginBoink
Diamond Member
There is lots of misinformation in this thread!
Okay, let me run down some things here...
Computer: there is no back door in EFS. There are two possible ways of recovering your data: recover the EFS certificate that was originally used to encrypt the files, or do a brute force attack against the entire keyspace. A brute force attack is what they call "computationally infeasible" and would likely take thousands, if not millions, of years to complete. Therefore, your only hope is to recover the original EFS certificate.
The EFS certificate on a machine that is part of a workgroup is automatically created by the operating system when a user first encrypts a file. I am not certain, but I believe the certificate is stored in c:\documents and settings\username\application data\microsoft\crypto\RSA. If you can get to that folder on the original hard drive, stop immediately and call a reputable data recovery shop. You probably stand an excellent chance of getting your data back.
I do not know if the files and settings transfer wizard backs up this data. You can try to find out. I'm launching WinXP now to look... unfortunately, it does not appear to do so.
How EFS Works: This is misunderstood by many here. Let's say I encrypt a file. When I do, the system generates a random number, known as the File Encryption Key (FEK), and encrypts the file with the FEK. The FEK is then encrypted with the user's public key from his EFS certificate. The encrypted FEK is stored with the encrypted file. Edit: The FEK is unique to each file. A new FEK is randomly generated for each encrypted file. So finding the FEK for one file does not allow you to decrypt any other file.
To decrypt the file, the user's private key from the user's EFS certificate must be used to decrypt the FEK, and the FEK is used to decrypt the contents of the file.
The EFS certificate is stored on the local machine, but the user's password must be used to decrypt the certificate itself. This is why an admin resetting a user's password is not sufficient to recover EFS data. EDIT: This is how all of those "break EFS" utilities work: they attack the user's password to recover the user's EFS cert. Since, in this case, the cert that was used to encrypt the files was never present on the hard drives on which the files reside, these utilities won't work in this situation.
The FEK can be encrypted with many users' public keys so that many users can decrypt the file. This is how recovery agents (if configured) work.
Computer, I agree that the UI should warn you about possible ramifications when encrypting your files. However, we can't do much about that now. The only way out for you is to recover your EFS cert from the old hard drive. Period.
Okay, let me run down some things here...
Computer: there is no back door in EFS. There are two possible ways of recovering your data: recover the EFS certificate that was originally used to encrypt the files, or do a brute force attack against the entire keyspace. A brute force attack is what they call "computationally infeasible" and would likely take thousands, if not millions, of years to complete. Therefore, your only hope is to recover the original EFS certificate.
The EFS certificate on a machine that is part of a workgroup is automatically created by the operating system when a user first encrypts a file. I am not certain, but I believe the certificate is stored in c:\documents and settings\username\application data\microsoft\crypto\RSA. If you can get to that folder on the original hard drive, stop immediately and call a reputable data recovery shop. You probably stand an excellent chance of getting your data back.
I do not know if the files and settings transfer wizard backs up this data. You can try to find out. I'm launching WinXP now to look... unfortunately, it does not appear to do so.
How EFS Works: This is misunderstood by many here. Let's say I encrypt a file. When I do, the system generates a random number, known as the File Encryption Key (FEK), and encrypts the file with the FEK. The FEK is then encrypted with the user's public key from his EFS certificate. The encrypted FEK is stored with the encrypted file. Edit: The FEK is unique to each file. A new FEK is randomly generated for each encrypted file. So finding the FEK for one file does not allow you to decrypt any other file.
To decrypt the file, the user's private key from the user's EFS certificate must be used to decrypt the FEK, and the FEK is used to decrypt the contents of the file.
The EFS certificate is stored on the local machine, but the user's password must be used to decrypt the certificate itself. This is why an admin resetting a user's password is not sufficient to recover EFS data. EDIT: This is how all of those "break EFS" utilities work: they attack the user's password to recover the user's EFS cert. Since, in this case, the cert that was used to encrypt the files was never present on the hard drives on which the files reside, these utilities won't work in this situation.
The FEK can be encrypted with many users' public keys so that many users can decrypt the file. This is how recovery agents (if configured) work.
Computer, I agree that the UI should warn you about possible ramifications when encrypting your files. However, we can't do much about that now. The only way out for you is to recover your EFS cert from the old hard drive. Period.
