EFS: decrypt files after lost pub/priv keys - possible?

[Generally Crazy]

Normally I find most answers on the WEB ... newsgroups always seem to be in
such CHAOS it is almost impossible to follow threads - but here I am, the
whipped dog ... caving. So here goes ... really need help w/this one.

Here's the situation I'm in ... small home office ... Windows 2000, SP2,
updated to SP4 ... networked to NT server 4.0 (sp6a) domain controller.
Accidentally compressing a folder ... encryption was selected instead
<distracted> . 2 drives "C:" and "D:" email was stored on "D:" so the
encrypted files are intact, not accessible. Before realizing EFS had hold
of the folder, "C:" disk was reformatted with NTFS to reinstall win2K
[OS/PROG difficulties] and apparently lost private/public keys for EFS to
decrypt the files. Doing some reading ... Win2K RK to the rescue.
EFSINFO.EXE recovered thumbprints. True, security is always an issue. In
this instance, it would be nice 2 stuff the thumbprint into the current
certificate as the local or domain administrator to recover data. Our data
isn't of national security - ask my other half and she'd SWEAR it was as her
email & address books are inaccessible.

<sample recovered info>
mailbox.pst: Encrypted
<Local User>
Users who can decrypt:
PAKRATS.NET\deb (CN=deb,L=EFS,OU=EFS File Encryption Certificate)
Certificate thumbprint: 1F2B 647D 4F2A FFCE 7350 6265 27DD BBE4 91BF
E225

<Domain Admin> MYSELF
Recovery Agents:
PAKRATS.NET\ed (OU=EFS File Encryption Certificate, L=EFS, CN=ed)
Certificate thumbprint: 76FF 6958 F092 784D B916 41F0 BFDB C72D 8849
1A33

Although listed as the RA, I constantly get "access denied" when attempting
to decrypt via Windows Explorer and DOS window using cipher.exe. Checked
the ownership & access properties, all OK. WWW search for info, tips &
tricks lead to some info. Followed some other directions to discover keys,
certs and whatever else to decrypt the files. I seem to recall the SAM
changes during every installation <for obvious reasons> there is a
possibility recovery is not possible. CAVE DWELLING seems to be a
reasonable resort 'cuz the other half is on the warpath!

Testing an EFS after market tool to see if it was in fact legit in it's
claims to recover EFS files said it could repair the file - trial version
returns 512 bytes of the file ... of which was garbage as it was compared to
another MAILBOX.PST. We have never had reason to use EFS before, so this is
an entirely new situation. Reading the security stuff posted here revealed
just about all the same info I have found on the WWW with some distressing
info relating to NON RECOVERABLE.

There are a total of 4 files I need to recover of the most important is
mailbox.pst. ASAP. MMMMMMM - any thoughts on this?

Dog House Dwelling, bread and water only,


Ed <aka General Crazy>

 

[Shawn Rabourn \(MS\)]

Microsoft PSS has tools you can try.

--Shawn
This posting is provided "AS IS" with no warranties and confers no rights.

Normally I find most answers on the WEB ... newsgroups always seem to be in
such CHAOS it is almost impossible to follow threads - but here I am, the
whipped dog ... caving. So here goes ... really need help w/this one.

Here's the situation I'm in ... small home office ... Windows 2000, SP2,
updated to SP4 ... networked to NT server 4.0 (sp6a) domain controller.
Accidentally compressing a folder ... encryption was selected instead
<distracted> . 2 drives "C:" and "D:" email was stored on "D:" so the
encrypted files are intact, not accessible. Before realizing EFS had hold
of the folder, "C:" disk was reformatted with NTFS to reinstall win2K
[OS/PROG difficulties] and apparently lost private/public keys for EFS to
decrypt the files. Doing some reading ... Win2K RK to the rescue.
EFSINFO.EXE recovered thumbprints. True, security is always an issue. In
this instance, it would be nice 2 stuff the thumbprint into the current
certificate as the local or domain administrator to recover data. Our data
isn't of national security - ask my other half and she'd SWEAR it was as her
email & address books are inaccessible.

<sample recovered info>
mailbox.pst: Encrypted
<Local User>
Users who can decrypt:
PAKRATS.NET\deb (CN=deb,L=EFS,OU=EFS File Encryption Certificate)
Certificate thumbprint: 1F2B 647D 4F2A FFCE 7350 6265 27DD BBE4 91BF
E225

<Domain Admin> MYSELF
Recovery Agents:
PAKRATS.NET\ed (OU=EFS File Encryption Certificate, L=EFS, CN=ed)
Certificate thumbprint: 76FF 6958 F092 784D B916 41F0 BFDB C72D 8849
1A33

Although listed as the RA, I constantly get "access denied" when attempting
to decrypt via Windows Explorer and DOS window using cipher.exe. Checked
the ownership & access properties, all OK. WWW search for info, tips &
tricks lead to some info. Followed some other directions to discover keys,
certs and whatever else to decrypt the files. I seem to recall the SAM
changes during every installation <for obvious reasons> there is a
possibility recovery is not possible. CAVE DWELLING seems to be a
reasonable resort 'cuz the other half is on the warpath!

Testing an EFS after market tool to see if it was in fact legit in it's
claims to recover EFS files said it could repair the file - trial version
returns 512 bytes of the file ... of which was garbage as it was compared to
another MAILBOX.PST. We have never had reason to use EFS before, so this is
an entirely new situation. Reading the security stuff posted here revealed
just about all the same info I have found on the WWW with some distressing
info relating to NON RECOVERABLE.

There are a total of 4 files I need to recover of the most important is
mailbox.pst. ASAP. MMMMMMM - any thoughts on this?

Dog House Dwelling, bread and water only,


Ed <aka General Crazy>

 

[Steven L Umbach]

Drive C that contained your operating system and user profiles also contained the EFS
private keys needed to decrypt those files. The EFS private keys are stored in the
users and recovery agent's [local administrator by fefault] profiles and unless you
have copies of those profiles in a backup from a time after those file were
encrypted, then those files are lost. --- Steve

Normally I find most answers on the WEB ... newsgroups always seem to be in
such CHAOS it is almost impossible to follow threads - but here I am, the
whipped dog ... caving. So here goes ... really need help w/this one.

Here's the situation I'm in ... small home office ... Windows 2000, SP2,
updated to SP4 ... networked to NT server 4.0 (sp6a) domain controller.
Accidentally compressing a folder ... encryption was selected instead
<distracted> . 2 drives "C:" and "D:" email was stored on "D:" so the
encrypted files are intact, not accessible. Before realizing EFS had hold
of the folder, "C:" disk was reformatted with NTFS to reinstall win2K
[OS/PROG difficulties] and apparently lost private/public keys for EFS to
decrypt the files. Doing some reading ... Win2K RK to the rescue.
EFSINFO.EXE recovered thumbprints. True, security is always an issue. In
this instance, it would be nice 2 stuff the thumbprint into the current
certificate as the local or domain administrator to recover data. Our data
isn't of national security - ask my other half and she'd SWEAR it was as her
email & address books are inaccessible.

<sample recovered info>
mailbox.pst: Encrypted
<Local User>
Users who can decrypt:
PAKRATS.NET\deb (CN=deb,L=EFS,OU=EFS File Encryption Certificate)
Certificate thumbprint: 1F2B 647D 4F2A FFCE 7350 6265 27DD BBE4 91BF
E225

<Domain Admin> MYSELF
Recovery Agents:
PAKRATS.NET\ed (OU=EFS File Encryption Certificate, L=EFS, CN=ed)
Certificate thumbprint: 76FF 6958 F092 784D B916 41F0 BFDB C72D 8849
1A33

Although listed as the RA, I constantly get "access denied" when attempting
to decrypt via Windows Explorer and DOS window using cipher.exe. Checked
the ownership & access properties, all OK. WWW search for info, tips &
tricks lead to some info. Followed some other directions to discover keys,
certs and whatever else to decrypt the files. I seem to recall the SAM
changes during every installation <for obvious reasons> there is a
possibility recovery is not possible. CAVE DWELLING seems to be a
reasonable resort 'cuz the other half is on the warpath!

Testing an EFS after market tool to see if it was in fact legit in it's
claims to recover EFS files said it could repair the file - trial version
returns 512 bytes of the file ... of which was garbage as it was compared to
another MAILBOX.PST. We have never had reason to use EFS before, so this is
an entirely new situation. Reading the security stuff posted here revealed
just about all the same info I have found on the WWW with some distressing
info relating to NON RECOVERABLE.

There are a total of 4 files I need to recover of the most important is
mailbox.pst. ASAP. MMMMMMM - any thoughts on this?

Dog House Dwelling, bread and water only,


Ed <aka General Crazy>

 

[Generally Crazy]

Drive C that contained your operating system and user profiles also contained the EFS
private keys needed to decrypt those files. The EFS private keys are stored in the
users and recovery agent's [local administrator by fefault] profiles and unless you
have copies of those profiles in a backup from a time after those file were
encrypted, then those files are lost. --- Steve

pardon the sarcastic humor, it's a NYC thing --- *G*

Steve - no, that's NOT a good answer ... hehehehehehe.
www.beginningtoseethelight.org - great resource. I believe I found
workable keys <or the remnants of possibilities> as the "user" directory
<documents&settings> has some older keys. I've already attempted to take
the system OFFLINE from the network and force it to try it's ADMIN keys - of
little success, so it's back to the original plan.

From all that I know as I've done coding for a number of years prior to the
windows explosion, export laws require master keys be provided to the FEDS
to qualify for export. Just so if they want to read something, they can
w/out the bull. Win2K EFS is exportable under US law. How the FEDS get the
keys is from those doing the encryption. Hence Microsoft DOES know how 2
fix this as they provided the MASTER keys. It's federal law - paranoid
lawyers, I'd imagine ... LOL.

In my isolated case I have discovered several base "KEYS" from the MFT by
doing a simple NTBACKUP. My only problem is order of alignment. Once this
alignment is established, the brute force approach becomes simplified,
although time consuming. We do have time ... as these are three 25K excel
files and one 250M outlook.pst file. So allowing a running progie on a
single P4 system coded in assembler will allow it to run at max speed, and
with a little luck, the "known test key patterns" generated against the EFS
service will HIT the necessary thumbprint --- yes, the data is that
important to us. At present, this project is going to require some EXTERNAL
help from the makers, so 2 speak. Others interested with input for this
project email me.

I don't do this for a living - so it is going to take some time - visual
anything & dotted net just don't work for me as it now presents a definitive
learning curve requirement. Although I am versed in several forms of DES,
this undertaking is requiring help and time. I have succeeded before
<another story> ... today is just another day to succeed again. Although I
should publish my findings, it has not come to light unless I'm pressed to
do so by those who also have suffered the same loss. My thought is this ...
admission to KNOWING how to do it by those empowered to fix what's broken
AND should be turned into a reliable repair service, of which I'm sure fees
would be exurbanite. Back to the "Do It Yourself" shelf ... LOL

Anyone else following this thread - BEWARE - a bit of a note on those
instruments which claim to be able to decrypt files - their algorithms they
say work - cannot work if you've done what I've done. They match up users
to what you get from "efsinfo.exe" output. This does NOT guarantee the file
is decryptable, as I have learned. There is no SELF TEST performed on the
output to assure successful recovery. Win2K (from what I can tell) does
establish a self-test good/bad in it's decryption process (ie. it knows if
it's right or wrong) - built in function so Win2K knows it can ACCESS the
data, hence: ACCESSABLE OR INACCESSIBLE. So if you cannot gain the first
512 bytes of the file header to match up to a known file system, save your
bucks because it won't work. Unless the aftermarket tools use the same
entry/exits that Win2K uses, understands what is sent back, their success is
varied.

As Steve has said ... if you blow up your Documents and Settings folders -
it is almost a worthless cause to try recovering the data.

I'll keep you good folks posted as to my results ... nothing is ever
impossible until you try. Encryption is written in code, any code can be
broken effectively - time is the requirement to successful decryption of any
encryption (self-encapsulated encryption only). So as we blowfish and sha
it, des'in it a bit with a bit of chump code, generators keep the power
flowing ... <rhetoric bull, I know>

 

[Drew Cooper [MSFT]]

There is no back door for feds. We couldn't have gotten Common Criteria
EAP4 if there were. The NSA wouldn't let US government employees use EFS if
there were a back door. We've even had 3rd party reviews of our EFS code -
I'll repeat: NO BACK DOORS.

Lucky for you, Win2k used DES for its symmetric encryption. Maybe you were
even using the "for export" version of Win2k - it had weak keys because of
government regulations about exporting crypto at the time. It would be
possible to crack each file individually in this case. It would still take
a lot of number-crunching and it would take a very long time on your single
machine.
Had you been running XP, the symmetric keys would have been AES 256 -
nobody's cracked that yet.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Drive C that contained your operating system and user profiles also contained the EFS
private keys needed to decrypt those files. The EFS private keys are stored in the
users and recovery agent's [local administrator by fefault] profiles and unless you
have copies of those profiles in a backup from a time after those file were
encrypted, then those files are lost. --- Steve

pardon the sarcastic humor, it's a NYC thing --- *G*

Steve - no, that's NOT a good answer ... hehehehehehe.
www.beginningtoseethelight.org - great resource. I believe I found
workable keys <or the remnants of possibilities> as the "user" directory
<documents&settings> has some older keys. I've already attempted to take
the system OFFLINE from the network and force it to try it's ADMIN keys - of
little success, so it's back to the original plan.

From all that I know as I've done coding for a number of years prior to the
windows explosion, export laws require master keys be provided to the FEDS
to qualify for export. Just so if they want to read something, they can
w/out the bull. Win2K EFS is exportable under US law. How the FEDS get the
keys is from those doing the encryption. Hence Microsoft DOES know how 2
fix this as they provided the MASTER keys. It's federal law - paranoid
lawyers, I'd imagine ... LOL.

In my isolated case I have discovered several base "KEYS" from the MFT by
doing a simple NTBACKUP. My only problem is order of alignment. Once this
alignment is established, the brute force approach becomes simplified,
although time consuming. We do have time ... as these are three 25K excel
files and one 250M outlook.pst file. So allowing a running progie on a
single P4 system coded in assembler will allow it to run at max speed, and
with a little luck, the "known test key patterns" generated against the EFS
service will HIT the necessary thumbprint --- yes, the data is that
important to us. At present, this project is going to require some EXTERNAL
help from the makers, so 2 speak. Others interested with input for this
project email me.

I don't do this for a living - so it is going to take some time - visual
anything & dotted net just don't work for me as it now presents a definitive
learning curve requirement. Although I am versed in several forms of DES,
this undertaking is requiring help and time. I have succeeded before
<another story> ... today is just another day to succeed again. Although I
should publish my findings, it has not come to light unless I'm pressed to
do so by those who also have suffered the same loss. My thought is this ....
admission to KNOWING how to do it by those empowered to fix what's broken
AND should be turned into a reliable repair service, of which I'm sure fees
would be exurbanite. Back to the "Do It Yourself" shelf ... LOL

Anyone else following this thread - BEWARE - a bit of a note on those
instruments which claim to be able to decrypt files - their algorithms they
say work - cannot work if you've done what I've done. They match up users
to what you get from "efsinfo.exe" output. This does NOT guarantee the file
is decryptable, as I have learned. There is no SELF TEST performed on the
output to assure successful recovery. Win2K (from what I can tell) does
establish a self-test good/bad in it's decryption process (ie. it knows if
it's right or wrong) - built in function so Win2K knows it can ACCESS the
data, hence: ACCESSABLE OR INACCESSIBLE. So if you cannot gain the first
512 bytes of the file header to match up to a known file system, save your
bucks because it won't work. Unless the aftermarket tools use the same
entry/exits that Win2K uses, understands what is sent back, their success is
varied.

As Steve has said ... if you blow up your Documents and Settings folders -
it is almost a worthless cause to try recovering the data.

I'll keep you good folks posted as to my results ... nothing is ever
impossible until you try. Encryption is written in code, any code can be
broken effectively - time is the requirement to successful decryption of any
encryption (self-encapsulated encryption only). So as we blowfish and sha
it, des'in it a bit with a bit of chump code, generators keep the power
flowing ... <rhetoric bull, I know>

 

[Generally Crazy]

Happy New Year Drew

Thanks for the heads up. I assume it is still possible, however lengthy, to
eventually decode the email file. I'd love to be plugged into a "Cray" for
a few days or any multi-processor tera-flop machine <G> DES? I assume it's
3DES? I have a stand alone DES machine - circa 1984 - by a now defunct
hardware company. The size of a full size external modem. Still works
correctly ;-)

Good point, as I assumed Win2K wuz shipped w/same EFS standard. Funny the
Feds don't require an add-on for Win2K. Which means my job just became
allot harder. I respect the security NT provided in the past. I continue 2
use NT Server 4.0 - it's enough for a small home office From what I am
reading - 2000 Server can store, serve and reciprocate keys - so that would
seem to be the better idea if I choose to keep EFS enabled in the future.

For now, every key, certificate and other related security information has
been exported, backed up by NTBACKUP, stored on the server *AND* stored on
CD. XP Pro edition wouldn't run properly on our hardware, so I am grateful.
DES 256 is 99.9% uncrackable, from the claims I've read. Hind sight is
truly 20-20!!

Wouldn't it be prudent to inform users of the pitfall a simple mistake could
make? Maybe offer a progie to enable/disable EFS easily for non-techie
users? Hate to see a simple twist of the wrist click the wrong box ...
makes for some really ticked off consumers. Just for argument sake, I
purchased a lottery ticket using the UID/SID number dissected from the
encrypted file <G>. If I hit - HA! Time 2 call IBM for a new multi
processor system - LOL!

On a GOOD NOTE: While rummaging through some ZIP disks, I did find another
email file 4 months old. It was a backup before we moved the PC to a new
location in September so most college class & related email is intact. My
other half is taking classes for her CPA. The prior homework, papers &
discussions are essential when it's time to take the CPA exam. I'm still in
the DOG HOUSE but the parole board is considerate ;-)

Thanks for everything - if you happen to come up with any other thoughts,
please feel free to let me know!

Ed - General Crazy

 

[Drew Cooper [MSFT]]

Which kind of DES depends. We initially used (plain ol') DES on Win2k RTM:
http://www.microsoft.com/technet/tr...nol/windows2000serv/deploy/confeat/nt5efs.asp
I don't remember which service pack added 3DES. Probably SP1 or SP2. If
you had a recent service pack installed, you were probably using 3DES.

In answer to your other questions:

Wouldn't it be prudent to inform users of the pitfall a simple mistake could
make?

Sure. Love to. How? Every good idea we've had (and even some really bad
ideas, too) has been shot down for one reason or another.

Maybe offer a progie to enable/disable EFS easily for non-techie
users?

Well . . . there's a reg setting, but I don't think that's really for
non-techie users. I, personally, would prefer to have EFS disabled by
default, but that idea met with a lot of resistance and was quickly shelved.
XP Home Edition doesn't have EFS - at least those non-techie users don't
have to worry about it.

Hate to see a simple twist of the wrist click the wrong box ...
makes for some really ticked off consumers.

Tell me about it. This is a common problem - check the newsgroups. It
doesn't give me any warm fuzzy feelings.


I don't suppose your other half's mail server is known, is it? If it's
school-related mail, there is probably another route to recover the mail - a
school IT department probably does regular backups.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Happy New Year Drew

Thanks for the heads up. I assume it is still possible, however lengthy, to
eventually decode the email file. I'd love to be plugged into a "Cray" for
a few days or any multi-processor tera-flop machine <G> DES? I assume it's
3DES? I have a stand alone DES machine - circa 1984 - by a now defunct
hardware company. The size of a full size external modem. Still works
correctly ;-)

Good point, as I assumed Win2K wuz shipped w/same EFS standard. Funny the
Feds don't require an add-on for Win2K. Which means my job just became
allot harder. I respect the security NT provided in the past. I continue 2
use NT Server 4.0 - it's enough for a small home office From what I am
reading - 2000 Server can store, serve and reciprocate keys - so that would
seem to be the better idea if I choose to keep EFS enabled in the future.

For now, every key, certificate and other related security information has
been exported, backed up by NTBACKUP, stored on the server *AND* stored on
CD. XP Pro edition wouldn't run properly on our hardware, so I am grateful.
DES 256 is 99.9% uncrackable, from the claims I've read. Hind sight is
truly 20-20!!

Wouldn't it be prudent to inform users of the pitfall a simple mistake could
make? Maybe offer a progie to enable/disable EFS easily for non-techie
users? Hate to see a simple twist of the wrist click the wrong box ...
makes for some really ticked off consumers. Just for argument sake, I
purchased a lottery ticket using the UID/SID number dissected from the
encrypted file <G>. If I hit - HA! Time 2 call IBM for a new multi
processor system - LOL!

On a GOOD NOTE: While rummaging through some ZIP disks, I did find another
email file 4 months old. It was a backup before we moved the PC to a new
location in September so most college class & related email is intact. My
other half is taking classes for her CPA. The prior homework, papers &
discussions are essential when it's time to take the CPA exam. I'm still in
the DOG HOUSE but the parole board is considerate ;-)

Thanks for everything - if you happen to come up with any other thoughts,
please feel free to let me know!

Ed - General Crazy

There is no back door for feds. We couldn't have gotten Common Criteria
EAP4 if there were. The NSA wouldn't let US government employees use

EFS