На стороне пользователя можно придумать алгоритм гарантирующий защиту :0. Допустим хранилище содержит только верифицированные, подписанные, доверительные публичные ключи. 1 ваш секретный ключ.
1. Бекапим папку ${HOME}/.gnupg
cp -pr ${HOME}/.gnupg ${HOME}/.gnupg_backup-20190708
2. Бекап публичных ключей:
gpg --armor --export --output pgp_public_keys-20190708.pub
Просмотр бекапа:
gpg --show-keys pgp_public_keys-2019.pub
Этими ключами можно обмениваться при личной встрече!
3. Теперь можно делать import ОДНОГО открытого ключа с сервера.
4. Смотрим импортированный ключ
gpg -- fingerprint
5. Верифицируем загруженный ключ и все ключи в нашей базе на сервере ключей.
Если не подвисло значит в нашей базе нет атакованных ключей.
Если подвисло, значит как минимум один ключ атакован.
Востанавливаем с бекапа ключи по одному и повторяем верификацию принудительно после каждого добавленного ключа.
Если верификация прошла ключ помещаем в белый список.
После импорта атакованого ключа система подвиснет.
Знаем ещё один атакованный ключ, вносим его в черный список, который при восстановления хранилища из бекапа не подгружаем.
Загруженную базу ключей с белого списка и принудительно верифицируем.
Если верификация не прошла, анулируем белый список и начинаем сначала, по одному ключу восстанавливать с бекапа.
Продолжаем пока все ключи с бекапа не будут востановлены и верифицированные, за исключением созданного чёрного списка.
Этот алгоритм необходимо использовать при импорте очередного публичного ключа.
В случае большого числа атакованный ключей, чёрный список разрастется и верификация через сервера будет невозможна.
Ключи в чёрном списке можно использовать для верификации в крыптографии, для верификации в офлайне руками, они могут быть импортированы в рабочей системе, но не могут в ней находится при верификации ключей с серверов ключей!
