man0war На сколько я помню , при регистрации в вебмани предлагают сохранить pfx (там все , и секретный и публичный и сертификат) . Потом его импортируют , и в зависимости от настроек (см.аттач) и от используемого криптопровайдера зависит способ хранения закрытого ключа . Т.е. для расшифровки этого ключа может потребоваться пароль введённый при импорте , могут потребоваться ещё некоторые файлы , точно не скажу какие , надо будет порыть . Короче ничего не удаляй пока .

Открытые ключи тут
\Documents and Settings\%USER%\Application Data\Microsoft\Crypto\RSA\S-1-5-21-299502267-839522115-1060284298-500\
Закрытые (пошифрованные) вроде бы тут - \Documents and Settings\%USER%\Application Data\Microsoft\Protect\S-1-5-21-299502267-839522115-1060284298-500\


56361882__Imppfx.png

infern0 „Можно ли обойти если она ранее не стояла - хз, надо пробовать.“

Я тоже хз , но думаю как-то можно , видимо где-то храниться признак , надо его найти и поправить . В файлах где лежат открытые , видно юникодовскую строку Export Flag , может оно ?

man0war „если ключ и сертификат в наличии , то каков шанс восстановления работоспособности ? “

Ну при условии , что требуемые файлы сохранились и учитывая что люди даже расшифровывают полностью винты (с чужих виндов) после EFS , то видимо возможно .

2 infern0:

"Однако счас глянул на своей машине - что-то файл из Keys не похож на закрытый ключ, надо подумать..."

Да , никакого сходства с ключами похоже нет.
Закрытые ключи лежат в \Documents and Settings\%USER%\Application Data\Microsoft\Crypto\RSA\
(Bogrus слегка ошибся , но в итоге всё равно подсказку
дал , спасибо) . А эту ветку , если она слетела не восстановить похоже :((

Там с открытыми нашёл лежат части закрытого ключа (модуль) , а свою экспоненту найти не могу , где-то зашифрована , возможно что в свопе . По крайней мере я только в нём нашёл юникодовкий текст "CryptoAPI Private Key" .

Во блин , теперь похоже понятно почему у тебя ругалось - в свойствах сертификата якобы ключ есть (потому что находит модуль) , а экспортировать не может , т.к. не находит экспоненту .

Так что , ищем тогда экспоненту ?

Еще отсюда вопрос возникает , если Microsoft заложила
в XP откат системы , то в данном случае , или это весьма сильный просчет разработчиков или я дурак ловко сделал откат :)) ,но всё-таки склоняюсь к первому варианту , потому что ничего сверх того , что заложено в этой процедуре я не делал.

2 bogrus :
Интересно , что легче - искать неизвестно где экспоненту или
поломать 1024-битный ключ RSA ? :)

man0war „Еще отсюда вопрос возникает “

Мы ещё не разобрались , а тебя сейчас больше волнует кто просчитался ? :)

Нашёл ссылку на русский вариант одной полезной статьи , берись тоже за чтиво .
http://klassnarod.narod.ru/EFS.rar

„Интересно , что легче - искать неизвестно где экспоненту или поломать 1024-битный ключ RSA ?“

Коротко говоря , второе просто невозможно :)

Вообще секретный (magic - RSA2) ключ состоит из таких частей :

modulus
prime1
prime2
exponent1
exponent2
coefficient
privateExponent

Имея некоторые из них можно найти экспоненту .

сильно сомневаюс что экспонента в свопе лежит, может в реестре. Это кстати объясняет почему она пропала после отката - реестр (system например) восстановился из резервной копии, в которой экспоненты просто не существовало. Вот и траблы.

2 Bogrus :
Sorry , если чем-то обидел.

infern0 , я делал откат до той даты , когда
сертификат уже был установлен . То есть по идее никаких траблов и быть не должно . Однако , увы...

Bogrus , спасибо огромное , статья просто в тему !!!

man0war Не мути воду тремя последними постами .

„я делал откат до той даты , когда сертификат уже был установлен “

Сначала ты говоришь что откат повлиял на твоё вебмани , теперь говоришь что делал откат ДО ТОГО КАК устанавливал сертификат и вообще вебмани . Это как понимать ?

bogrus
Я так понял что если он установил вебмани, допустим 10-го, а откат делал допустим 12-го до 11-го. То есть вся инфа должна была сохранится - ведь 11-го она уже была...

Вот некоторая инфа о хранении закрытых ключей (есть ещё ссылки) :
http://www.osp.ru/win2000/2003/04/063.htm (rus)
http://www.microsoft.com/resources/documentation/windows/2000/server/r eskit/en-us/distsys/part2/dsgch15.mspx (eng) - здесь более полное описание .

How Private Keys Are Stored
Private keys for the Microsoft RSA-based CSPs, including the Base CSP and the Enhanced CSP, reside in the user profile under RootDirectory\Documents and Settings\<username>\Application Data\Microsoft\Crypto\RSA.
Unlike their corresponding public keys, private keys must be protected. Therefore, all files in the RSA folder are automatically encrypted with a random, symmetric key called the user's master key. The user's master key is generated by the RC4 algorithm in the Base or Enhanced CSP. RC4 generates a 128-bit key for computers with the Enhanced CSP (subject to cryptography export restrictions) and a 56-bit key for computers with only the Base CSP (available for all Windows 2000 computers). The master key is generated automatically and is renewed periodically. It encrypts each file in the RSA folder automatically as the file is created.
The RSA folder must never be renamed or moved because this is the only place the CSPs look for private keys. Therefore, it is advisable to provide additional security.

Protect Folder
The user's master key is itself encrypted automatically by the Protected Storage service and stored in the user profile under RootDirectory\Documents and Settings\<username>\Application Data\Microsoft\Protect. For a domain user who has a roaming profile, the master key resides on the domain controller and is downloaded to the user's profile on the local computer until the computer is restarted.
The user's master key is encrypted twice, and each instance of encryption is stored in one of two parts of the Protect file. The first part, the password encryption key, is produced by the Hash-Based Message Authentication Code (HMAC) and SHA1 message digest function and is a hash of:
• A symmetric encryption of the user's master key produced by 160-bit RC4.
• The user's security identifier (SID).
• The user's logon password.
The second part is the backup/restore form of the master key. This is needed if the user's password is changed on one computer but the keys are in the user profile on another computer, or if the administrator resets the user's password. In either case, the Protected Storage service, which cannot detect password changes to update Part 1, uses Part 2 to recover the master key and regenerate Part 1.
To create the backup part of the file, the encrypted user's master key is sent on to the Protected Storage service on the domain controller. That service uses HMAC and SHA1 again to make a hash of the data it has received along with the domain controller's own backup/restore master key, and sends that back to the user's computer to store in the Protect file. These transmissions are authenticated (signed and encrypted) by way of remote procedure calls so that the user's master key never goes over the wire in plaintext.
The System Certificates, RSA, and Protect folders have their system attributes set. This prevents the files in them from being encrypted by EFS, which would make them inaccessible.

man0war только ты можешь посмотреть , что у тебя там могло поменяться (я подчеркнул) , потом можно будет решать дальше .