encrypting

[chuckles_2004]

i did a clean sweep on my laptop and now i cannot access
encrypted files on my ext hdd what can i do

[Jupiter Jones [MVP]]

Did you back-up the necessary files BEFORE formatting?
If not, your data may effectively be gone for good:
http://www3.telus.net/dandemar/encrypt.htm

--
Jupiter Jones [MVP]
http://www3.telus.net/dandemar/


"chuckles_2004" > wrote in message
...
>i did a clean sweep on my laptop and now i cannot access
> encrypted files on my ext hdd what can i do

[Jupiter Jones [MVP]]

The password will not do any good without the necessary files if EFS was
used.

--
Jupiter Jones [MVP]
http://www3.telus.net/dandemar/


"Tom H" > wrote in message
news:Q3jEd.36680$Xk.8599@pd7tw3no...
> If you know what the pw was, you stand a good chance ...

[Tom H]

With the correct pw the files can be regnerated.

"Jupiter Jones [MVP]" > wrote in message
...
> The password will not do any good without the necessary files if EFS was
> used.
>
> --
> Jupiter Jones [MVP]
> http://www3.telus.net/dandemar/
>
>
> "Tom H" > wrote in message
> news:Q3jEd.36680$Xk.8599@pd7tw3no...
>> If you know what the pw was, you stand a good chance ...
>
>

[Jupiter Jones [MVP]]

Tom;
Not if the files are encrypted.
Otherwise EFS would be worthless.
EFS is very secure when use properly.

Do not confuse EFS with NTFS Permissions.

--
Jupiter Jones [MVP]
http://www3.telus.net/dandemar/


"Tom H" > wrote in message
news:yhkEd.38402$8l.18430@pd7tw1no...
> With the correct pw the files can be regnerated.
>
> "Jupiter Jones [MVP]" > wrote in message
> ...
>> The password will not do any good without the necessary files if EFS was
>> used.
>>
>> --
>> Jupiter Jones [MVP]
>> http://www3.telus.net/dandemar/
>>
>>
>> "Tom H" > wrote in message
>> news:Q3jEd.36680$Xk.8599@pd7tw3no...
>>> If you know what the pw was, you stand a good chance ...
>>
>>
>
>

[Tom H]

Straight from the horses' mouth boys,

"http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_uizt.asp"

"If the certificate is not available, the private key will not be available,
and the user will not be able to decrypt the file."


So, at first blush you would appear to be correct, Jupiter. I've looked and
I can't find details on the algorithm that creates the key pairs. However,
if (BIG if, mind you) the only input to this algorithm is a pw, does it not
stand to reason that if one had the same, original pw, and the same exact
tool, one could re-create the same exact public/private key pair?
Does anyone know the secret of the creation of the key pairs?

[Mike Brannigan [MSFT]]

"Tom H" > wrote in message
news:OWnEd.40759$6l.5948@pd7tw2no...
> Straight from the horses' mouth boys,
>
> "http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_uizt.asp"
>
> "If the certificate is not available, the private key will not be
> available, and the user will not be able to decrypt the file."
>
>
> So, at first blush you would appear to be correct, Jupiter. I've looked
> and I can't find details on the algorithm that creates the key pairs.
> However, if (BIG if, mind you) the only input to this algorithm is a pw,
> does it not stand to reason that if one had the same, original pw, and the
> same exact tool, one could re-create the same exact public/private key
> pair?

> Does anyone know the secret of the creation of the key pairs?
>

Yes, and it has nothing to do with a users password.
If you do not have the certificate and you do not have a key recovery agent
(and its certificate available) then you will not be able to recover the
files.

--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Tom H" > wrote in message
news:OWnEd.40759$6l.5948@pd7tw2no...
> Straight from the horses' mouth boys,
>
> "http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_uizt.asp"
>
> "If the certificate is not available, the private key will not be
> available, and the user will not be able to decrypt the file."
>
>
> So, at first blush you would appear to be correct, Jupiter. I've looked
> and I can't find details on the algorithm that creates the key pairs.
> However, if (BIG if, mind you) the only input to this algorithm is a pw,
> does it not stand to reason that if one had the same, original pw, and the
> same exact tool, one could re-create the same exact public/private key
> pair?
> Does anyone know the secret of the creation of the key pairs?
>
>

[Steve Riley [MSFT]]

EFS uses DPAPI (data protection API) to generate the keys.

Here is how a user's password relates to DPAPI. For every user on a computer,
DPAPI generates a strong master key. To protect this key, DPAPI uses PKCS
#5 to generate a key from the user's password and encrypts the master key
with this password-derived key. DPAPI then stores the encrypted master key
in the user's profile.

This master key is used to protect every other key generated by DPAPI, including
the symmetric file encryption key (FEK) and the keys used to protect the FEK.

Steve Riley




> "Tom H" > wrote in message
> news:OWnEd.40759$6l.5948@pd7tw2no...
>
>> Straight from the horses' mouth boys,
>>
>> "http://www.microsoft.com/resources/documentation/Windows/XP/all/resk
>> it/en-us/Default.asp?url=/resources/documentation/windows/xp/all/resk
>> it/en-us/prnb_efs_uizt.asp"
>>
>> "If the certificate is not available, the private key will not be
>> available, and the user will not be able to decrypt the file."
>>
>> So, at first blush you would appear to be correct, Jupiter. I've
>> looked and I can't find details on the algorithm that creates the key
>> pairs. However, if (BIG if, mind you) the only input to this
>> algorithm is a pw, does it not stand to reason that if one had the
>> same, original pw, and the same exact tool, one could re-create the
>> same exact public/private key pair?
>>
>> Does anyone know the secret of the creation of the key pairs?
>>
> Yes, and it has nothing to do with a users password.
> If you do not have the certificate and you do not have a key recovery
> agent
> (and its certificate available) then you will not be able to recover
> the
> files.
> Mike
> --
> Mike Brannigan [Microsoft]
> This posting is provided "AS IS" with no warranties, and confers no
> rights
>
> Please note I cannot respond to e-mailed questions, please use these
> newsgroups
>
> "Tom H" > wrote in message
> news:OWnEd.40759$6l.5948@pd7tw2no...
>
>> Straight from the horses' mouth boys,
>>
>> "http://www.microsoft.com/resources/documentation/Windows/XP/all/resk
>> it/en-us/Default.asp?url=/resources/documentation/windows/xp/all/resk
>> it/en-us/prnb_efs_uizt.asp"
>>
>> "If the certificate is not available, the private key will not be
>> available, and the user will not be able to decrypt the file."
>>
>> So, at first blush you would appear to be correct, Jupiter. I've
>> looked
>> and I can't find details on the algorithm that creates the key pairs.
>> However, if (BIG if, mind you) the only input to this algorithm is a
>> pw,
>> does it not stand to reason that if one had the same, original pw,
>> and the
>> same exact tool, one could re-create the same exact public/private
>> key
>> pair?
>> Does anyone know the secret of the creation of the key pairs?

[Tom H]

Just out of curiosity, when the microsoft cryptography API wants to create a
'random' number --- ie for the purpose of creating un-recreatable key pairs,
how does it do it?
If not solely by using a text pw as input, what does it do to make a set of
bits that are different-by-design? It's an interesting conundrum because
digital computing devices don't do that kind of thing well, they are
marvelously good at arriving at exactly the same outputs, not good at
creating unpredictable, different each time outputs. Or is it a secret? I
promise not to tell ANYONE!
According to a book I read about how spy agencies generated their one-time
pads during the cold war, the KGB had a microphone outside of their HQ that
picked up random traffic noise and the signal from that was processed into
a random bitstream, while the CIA had a radio reciever (HF) tuned to a
static laden portion of the RF spectra and processed the random clicks and
pops into a secure, unreproducable bitstream.

"Steve Riley [MSFT]" > wrote in message
...
> EFS uses DPAPI (data protection API) to generate the keys.
>
> Here is how a user's password relates to DPAPI. For every user on a
> computer, DPAPI generates a strong master key. To protect this key, DPAPI
> uses PKCS #5 to generate a key from the user's password and encrypts the
> master key with this password-derived key. DPAPI then stores the encrypted
> master key in the user's profile.
>
> This master key is used to protect every other key generated by DPAPI,
> including the symmetric file encryption key (FEK) and the keys used to
> protect the FEK.
>
> Steve Riley
>
>
>
>
>> "Tom H" > wrote in message
>> news:OWnEd.40759$6l.5948@pd7tw2no...
>>
>>> Straight from the horses' mouth boys,
>>>
>>> "http://www.microsoft.com/resources/documentation/Windows/XP/all/resk
>>> it/en-us/Default.asp?url=/resources/documentation/windows/xp/all/resk
>>> it/en-us/prnb_efs_uizt.asp"
>>>
>>> "If the certificate is not available, the private key will not be
>>> available, and the user will not be able to decrypt the file."
>>>
>>> So, at first blush you would appear to be correct, Jupiter. I've
>>> looked and I can't find details on the algorithm that creates the key
>>> pairs. However, if (BIG if, mind you) the only input to this
>>> algorithm is a pw, does it not stand to reason that if one had the
>>> same, original pw, and the same exact tool, one could re-create the
>>> same exact public/private key pair?
>>>
>>> Does anyone know the secret of the creation of the key pairs?
>>>
>> Yes, and it has nothing to do with a users password.
>> If you do not have the certificate and you do not have a key recovery
>> agent
>> (and its certificate available) then you will not be able to recover
>> the
>> files.
>> Mike
>> --
>> Mike Brannigan [Microsoft]
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights
>>
>> Please note I cannot respond to e-mailed questions, please use these
>> newsgroups
>>
>> "Tom H" > wrote in message
>> news:OWnEd.40759$6l.5948@pd7tw2no...
>>
>>> Straight from the horses' mouth boys,
>>>
>>> "http://www.microsoft.com/resources/documentation/Windows/XP/all/resk
>>> it/en-us/Default.asp?url=/resources/documentation/windows/xp/all/resk
>>> it/en-us/prnb_efs_uizt.asp"
>>>
>>> "If the certificate is not available, the private key will not be
>>> available, and the user will not be able to decrypt the file."
>>>
>>> So, at first blush you would appear to be correct, Jupiter. I've
>>> looked
>>> and I can't find details on the algorithm that creates the key pairs.
>>> However, if (BIG if, mind you) the only input to this algorithm is a
>>> pw,
>>> does it not stand to reason that if one had the same, original pw,
>>> and the
>>> same exact tool, one could re-create the same exact public/private
>>> key
>>> pair?
>>> Does anyone know the secret of the creation of the key pairs?
>
>

[Steve Riley [MSFT]]

DPAPI (which is part of CryptoAPI) doesn't use the password when it generates
keys. Let me draw a simple picture of what I wrote below.

create new account on computer
|
put password on account
|
generate new master key for this account
|
generate PKCS #5 key-from-password
|
encrypt master key with key-from-password; discard key-from-password
|
store master key in user profile



Now say you encrypt a file. This happens:

retrieve master key from profile
|
generate PKCS #5 key-from-password
|
decrypt master key
|
open key store and retrieve EFS private key
|
decrypt EFS private key using master key
|
generate symmetric FEK
|
encrypt file with FEK
|
encrypt FEK with EFS private key


You're right that there's a lot of "random" number generation going on here.
CryptoAPI includes a function called CryptGenRandom() that generates cryptographically
random numbers but alas I don't know how it does it. These numbers are much
more random than what you'd get with the functions in typical compilers.
CryptGenKey(), the function that generates keys, follows similar logic.

Steve Riley




> Just out of curiosity, when the microsoft cryptography API wants to
> create a
> 'random' number --- ie for the purpose of creating un-recreatable key
> pairs,
> how does it do it?
> If not solely by using a text pw as input, what does it do to make a
> set of
> bits that are different-by-design? It's an interesting conundrum
> because
> digital computing devices don't do that kind of thing well, they are
> marvelously good at arriving at exactly the same outputs, not good at
> creating unpredictable, different each time outputs. Or is it a
> secret? I
> promise not to tell ANYONE!
> According to a book I read about how spy agencies generated their
> one-time
> pads during the cold war, the KGB had a microphone outside of their HQ
> that
> picked up random traffic noise and the signal from that was processed
> into
> a random bitstream, while the CIA had a radio reciever (HF) tuned to a
> static laden portion of the RF spectra and processed the random clicks
> and
> pops into a secure, unreproducable bitstream.
> "Steve Riley [MSFT]" > wrote in message
> ...
>
>> EFS uses DPAPI (data protection API) to generate the keys.
>>
>> Here is how a user's password relates to DPAPI. For every user on a
>> computer, DPAPI generates a strong master key. To protect this key,
>> DPAPI uses PKCS #5 to generate a key from the user's password and
>> encrypts the master key with this password-derived key. DPAPI then
>> stores the encrypted master key in the user's profile.
>>
>> This master key is used to protect every other key generated by
>> DPAPI, including the symmetric file encryption key (FEK) and the keys
>> used to protect the FEK.
>>
>> Steve Riley
>>
>>> "Tom H" > wrote in message
>>> news:OWnEd.40759$6l.5948@pd7tw2no...
>>>> Straight from the horses' mouth boys,
>>>>
>>>> "http://www.microsoft.com/resources/documentation/Windows/XP/all/re
>>>> sk
>>>> it/en-us/Default.asp?url=/resources/documentation/windows/xp/all/re
>>>> sk it/en-us/prnb_efs_uizt.asp"
>>>>
>>>> "If the certificate is not available, the private key will not be
>>>> available, and the user will not be able to decrypt the file."
>>>>
>>>> So, at first blush you would appear to be correct, Jupiter. I've
>>>> looked and I can't find details on the algorithm that creates the
>>>> key pairs. However, if (BIG if, mind you) the only input to this
>>>> algorithm is a pw, does it not stand to reason that if one had the
>>>> same, original pw, and the same exact tool, one could re-create the
>>>> same exact public/private key pair?
>>>>
>>>> Does anyone know the secret of the creation of the key pairs?
>>>>
>>> Yes, and it has nothing to do with a users password.
>>> If you do not have the certificate and you do not have a key
>>> recovery
>>> agent
>>> (and its certificate available) then you will not be able to recover
>>> the
>>> files.
>>> Mike
>>> --
>>> Mike Brannigan [Microsoft]
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights
>>> Please note I cannot respond to e-mailed questions, please use these
>>> newsgroups
>>>
>>> "Tom H" > wrote in message
>>> news:OWnEd.40759$6l.5948@pd7tw2no...
>>>> Straight from the horses' mouth boys,
>>>>
>>>> "http://www.microsoft.com/resources/documentation/Windows/XP/all/re
>>>> sk
>>>> it/en-us/Default.asp?url=/resources/documentation/windows/xp/all/re
>>>> sk it/en-us/prnb_efs_uizt.asp"
>>>>
>>>> "If the certificate is not available, the private key will not be
>>>> available, and the user will not be able to decrypt the file."
>>>>
>>>> So, at first blush you would appear to be correct, Jupiter. I've
>>>> looked
>>>> and I can't find details on the algorithm that creates the key
>>>> pairs.
>>>> However, if (BIG if, mind you) the only input to this algorithm is
>>>> a
>>>> pw,
>>>> does it not stand to reason that if one had the same, original pw,
>>>> and the
>>>> same exact tool, one could re-create the same exact public/private
>>>> key
>>>> pair?
>>>> Does anyone know the secret of the creation of the key pairs?