|
From: Anton A. <ai...@ca...> - 2007-09-19 08:01:07
|
Hi Matthew, On 17 Sep 2007, at 16:10, Matthew A. Postiff wrote: > Thanks for the quick replies. /dev/sda1 is an external USB hard > drive. The copying involved simply dragging/dropping various > unencrypted directories/files from my WinXP documents dir to the > external USB drive. Then I right-clicked those directories on the > USB drive and told XP to encrypt them. Great! I was worried when you said backup that you used some backup application that went and did something weird... > Since my XP system crashed, I unhooked the USB drive from it and > attached it as /dev/sda1 to my Linux system. > > I now understand what you are saying about the FEK being in the > MFT, though I don't know the significance of that fact in my > particular case. The FEK is the key that allows you to decrypt the file. Without it it is impossible to do the decryption (unless you were to brute force it and happened to have more computing power than all computers on the planet put together at your disposal!). The FEK is stored in the $LOGGED_UTILITY_STREAM:$EFS attribute in the MFT record of each encrypted file. Things are not quite so simple as the FEK is encrypted with another key (this is an RSA key). Thus you need the RSA private key to be able to decrypt the FEK and thus to be able to decrypt the file. The RSA private key is what is stored in the .pfx file when you export your private key in Windows hence why we need the .pfx file. We parse it then decrypt the .pfx file using the password you give to ntfsdecrypt then this gives us the RSA key which we use to decrypt the FEK in the $EFS attribute and then we use the decrypted FEK to decrypt the file data. > I applied your patch, rebuilt, and re-ran ntfsdecrypt, with exactly > the same result as in my previous email. Sorry my patch did not quite do what I intended! Could you revert that patch and apply the attached one instead and try again? Thanks! |
