id: Гость   вход   регистрация
текущее время 15:51 23/11/2017
Автор темы: int_0x0, тема открыта 06/07/2015 20:47 Печать
Категории: криптография, ошибки и баги, управление ключами, операционные системы
https://www.pgpru.com/Форум/РаботаСGnuPG/НеПодходитПарольПослеВостановленияИзBackup
создать
просмотр
ссылки

Не подходит пароль после восcтановления из backup


Забэкапил в своё время папку .gnupg. Сегодня потребовалось восстановить. Просто скопировал все файлы из бэкапа в папку /.gnupg. Дальше потребовалось расшифровать файл. Тут и проблема, пароль не подходит. Пароль у меня хранится в KeePass. Ввожу верно. Пароль не менялся.
Что я делаю неверно? Возможно не правильно восстановил из бэкапа?


 
Комментарии
— SATtva (07/07/2015 07:35)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Вряд ли, содержимое директории ~/.gnupg в дефолтной конфигурации самодостаточно. Разве что в бэкапе хранилась копия закрытого ключа с другим паролем.


Проблема точно именно в неверном пароле? При расшифровании из консоли не выводятся ли какие-то более специфические ошибки? Ну, и попробуйте вспомнить, меняли ли Вы пароль ключа после того, как сделали бэкап.
— pgprubot (08/07/2015 01:05, исправлен 08/07/2015 01:06)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Файл, зашифрованный ключом из кейринга в ~/.gnupg, который (кейринг) вы когда-то бэкапили?

— int_0x0 (08/07/2015 01:24)   профиль/связь   <#>
комментариев: 4   документов: 1   редакций: 1
Проблема точно именно в неверном пароле?

Да, ни сменить пароль не расшифровать файл.

Ну, и попробуйте вспомнить, меняли ли Вы пароль ключа после того, как сделали бэкап.

Нет, не менял. Были сгенерированы ключи. Публичный ключ отправлен на сервер, где нужно было делать бэкапы, криптовать и отправлять на dropbox. А вся папка gnupg была забэаплена отдельно.

При этом все даты изменения файлов в .gnupg на сервере и в папке бэкапа соответствуют той дате, когда всё это было сделано. Я полагаю, что если бы пароль менялся, то даты изменения были бы другими.

Файл, зашифрованный ключом из кейринга в /.gnupg, который (кейринг) вы когда-то бэкапили?

Не совсем понял о чем речь. Вот что бэкапилось:
— pgprubot (08/07/2015 01:50, исправлен 08/07/2015 01:53)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Аналогично.


Дальше потребовалось расшифровать файл.

Какой файл? Т.е. чем он был зашифрован? GnuPG поддреживает симметричное и асимметричное шифрование. У вас точно было последнее?


То, что вы описываете, быть не может, значит, ошибка либо в KeePass (например, новая версия несовместима со старой), либо в ваших действиях.


Как ещё одна параноя-версия: вы расшифровыввете файлы, которые лежали на серверах. Кто-то намеренно их изменил так, что они более не расшифровываются. ☺ Проставить нужные даты изменений в метаданных — не проблема.

— int_0x0 (08/07/2015 02:05, исправлен 08/07/2015 02:06)   профиль/связь   <#>
комментариев: 4   документов: 1   редакций: 1
Какой файл? Т.е. чем он был зашифрован? GnuPG поддреживает симметричное и асимметричное шифрование. У вас точно было последнее?

У меня на сервере есть база данных. Она архивируется и криптуется командой:


Расшифровываю:

— pgprubot (08/07/2015 07:04, исправлен 08/07/2015 07:07)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

OK, значит, шифровалось ключом с идентификатором backup_man.



Не стоит усложнять вещи раньше времени. Первое: gpg -K выдаёт наличие приватного ключа? Второе: если да, то попытайтесь сделать gpg --edit-key backup_man, потом выполните в консоли passwd. Это смена пароля на приватный ключ. Если пароль неверный, он не даст его сменить. Т.е. для теста вашего утеряного пароля никакие файлы и расшифровывания не нужны в принципе.


Ещё стоит посмотреть в сторону состава подключей в backup_man. Он изменялся?

— int_0x0 (08/07/2015 11:58, исправлен 08/07/2015 11:59)   профиль/связь   <#>
комментариев: 4   документов: 1   редакций: 1
Первое: gpg -K выдаёт наличие приватного ключа?

Да.


Второе: если да, то попытайтесь сделать , потом выполните в консоли passwd. Это смена пароля на приватный ключ. Если пароль неверный, он не даст его сменить. Т.е. для теста вашего утеряного пароля никакие файлы и расшифровывания не нужны в принципе.

Неверный пароль.


Ещё стоит посмотреть в сторону состава подключей в backup_man. Он изменялся?

Подключи я не добавлял.


А можно ли как-то посмотреть целостность приватного ключа? Он у меня хранился на зеркальном RAID массиве. Один диск в этом массиве выходил из строя. Может в процессе восстановления что-то случилось.

— SATtva (08/07/2015 12:16)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046
Для зашифрованного ключевого материала используется аналог MDC (в целях защиты от ряда атак), так что при повреждении gpg сразу бы выдал предупреждение.

Ещё один вариант: настройки кодировки консольного ввода не менялись? Изначально пароль мог вводиться не в той кодировке, которая установлена сейчас.
— int_0x0 (08/07/2015 12:36)   профиль/связь   <#>
комментариев: 4   документов: 1   редакций: 1
Ещё один вариант: настройки кодировки консольного ввода не менялись? Изначально пароль мог вводиться не в той кодировке, которая установлена сейчас.

Да, менял с en-US.UTF-8 на ru-RU.UTF-8. Вернул обратно, плюс потестил на win (kleopatra) – результат тот же.

Видимо уже ничего не поможет. Благо данные не критичные потеряны. Отныне буду хранить секретный ключ на нескольких сменных носителях ;)

SATtva, pgprubot, спасибо за помощь.
— SATtva (08/07/2015 13:00)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Ну, это смена локали, но не кодировки, так что не должно было повлиять. Странная ситуация.
— pgprubot (08/07/2015 18:47)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70
Насколько я знаю, локаль и кодировка не влияют на пароли, если они вводятся только на латинице.
— SATtva (09/07/2015 09:46)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046
Да, латиница, цифры, символы из ASCII-набора безопасны.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3