— SATtva (07/07/2015 07:35)   

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


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

— pgprubot (08/07/2015 01:05, исправлен 08/07/2015 01:06)   

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

— int_0x0 (08/07/2015 01:24)   

Проблема точно именно в неверном пароле?

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

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

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

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

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

Не совсем понял о чем речь. Вот что бэкапилось:
-rwx------+ 1 root root 9154 Окт 3 2014 gpg.conf -rwx------+ 1 root root 2190 Окт 3 2014 pubring.gpg -rwx------+ 1 root root 2190 Окт 3 2014 pubring.gpg~ -rwx------+ 1 root root 600 Окт 3 2014 random_seed -rwx------+ 1 root root 4848 Окт 3 2014 secring.gpg -rwx------+ 1 root root 1280 Окт 3 2014 trustdb.gpg

— pgprubot (08/07/2015 01:50, исправлен 08/07/2015 01:53)   

Аналогично.

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

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

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

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

— int_0x0 (08/07/2015 02:05, исправлен 08/07/2015 02:06)   

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

У меня на сервере есть база данных. Она архивируется и криптуется командой:
gpg --trust-model=always --yes -e -r backup_man -o backup.7z.gpg backup.7z

Расшифровываю:
gpg -o backup.7z -d backup.7z.gpg

— pgprubot (08/07/2015 07:04, исправлен 08/07/2015 07:07)   

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)   

Первое: gpg -K выдаёт наличие приватного ключа?

Да.

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

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

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

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

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

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

Ещё один вариант: настройки кодировки консольного ввода не менялись? Изначально пароль мог вводиться не в той кодировке, которая установлена сейчас.

— int_0x0 (08/07/2015 12:36)   

Ещё один вариант: настройки кодировки консольного ввода не менялись? Изначально пароль мог вводиться не в той кодировке, которая установлена сейчас.

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

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

SATtva, pgprubot, спасибо за помощь.

— SATtva (08/07/2015 13:00)   

Ну, это смена локали, но не кодировки, так что не должно было повлиять. Странная ситуация.

— pgprubot (08/07/2015 18:47)   
Насколько я знаю, локаль и кодировка не влияют на пароли, если они вводятся только на латинице.

— SATtva (09/07/2015 09:46)   
Да, латиница, цифры, символы из ASCII-набора безопасны.