LINUX.ORG.RU

Спецы по PGP, нужна ваша помощь

 


0

4

Возникла проблема с GnuPG. Есть данные, которые шифруются с помощью GnuPG (через gnupg-agent), в чистом виде данные от 15 до 20 байт (текст). Так вот процесс зашифровки (encrypt) работает быстро, а вот расшифровка обратно (decrypt) работает в 60 раз медленнее. Уже что только не пробовал (разные версии, разные дистрибутивы и тд), увеличивал энтропию (haveged, но вроди как для decrypt энтропия не нужна), но результат примерно одинаковый. Результаты тестов: при шифровании текста 12345678912345678 с ключем 4096, тысяча циклов - в среднем 2 секунды, а вот расшифровать обратно тысяча циклов занимает аж 2 минуты. Единственное что получилось сделать для ускорения - это убрать пароль с ключа, тогда тысяча циклов расшифровки занимает 11 сек, а не 2 минуты, но этот вариант не годится, т.к. пароль нужен.

Или же тут уже ничего не сделаешь и нужно смириться с тем что PGP при расшифровке так небыстро работает? С чем это связано?

★★★

А если чуть-чуть забороть паранойу? и взять ключ на 2048?

If you need more security than RSA-2048 offers, the way to go would be to switch to elliptical curve cryptography — not to continue using RSA.

gutaper ★★★★ ()
Последнее исправление: gutaper (всего исправлений: 1)
Ответ на: комментарий от gutaper

Ключ 2048 «ускоряет» процесс дешифровки на тысячу циклов на пару секунд, так что в целом картину это не меняет.

FreeBSD ★★★ ()

Не скажу точно на счёт GPG, но это обычная ситуация для разных методов асимметричного шифрования - скорости шифрования и дешифрования, подписи и валидации различаются. Причём как раз таки в разы.

DawnCaster ()

Так проблема в пароле выходит. Твой тест вообще ни о чем не говорит. Либо поменяй вопрос и, соответственно, запрос в гугле, либо страдай же.

Anoxemian ★★★★★ ()

Измерьте зависимость времени от размера данных. Наверняка дело не в дешифровании как таковом, а в накладных расходах на IPC для безопасной расшифровки закрытого ключа.

anonymous ()
Ответ на: комментарий от anonymous

Наверняка дело не в дешифровании как таковом, а в накладных расходах на IPC для безопасной расшифровки закрытого ключа.

Да, похоже что именно в этом и дело. Вопрос тут один - можно ли каким-то образом ускорить всё это? Добавление ресурсов (проц/память) не влияет.

FreeBSD ★★★ ()
Ответ на: комментарий от FreeBSD

Сам алгоритм RSA не предусматривает шифрование приватного ключа паролем - скорей всего GnuPG шифрует приватник на какой-то сардельке из SHA/AES и тому подобное.

Как вариант - сам реализуй шифрование приватника, а GnuPG скармливай уже его в чистом виде.

Novator ★★★★ ()

может в настройках gpg где то есть кэширование пароля?

icefreeze ()
Ответ на: комментарий от icefreeze

Это всё добавлено, опции

--max-cache-ttl 34560000 --default-cache-ttl 34560000

но это тоже не решает проблему.

FreeBSD ★★★ ()

Насколько я помню в GnuPGP используется параноидальный механизм работы с зашифрованым приватным ключем. Тоесть они его нигде не хранять после расшифровки, если нужен ключ на какойто итерации то его расшифровывают - используют, и тутже затирают буфер где он хранился. Когда ключ нужен на второй итерации - процедура повторяется ...

Такчто есть смысл задуматся шифровать ключ отдельно (темже openssl) а gnupgp уже давать не зашифрованный приватный ключ.

zaz ★★★★ ()
Ответ на: комментарий от zaz

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

На текущем этапе удалось запустить несколько инстансев gpg-agent (каждый в своей директории). Это позволяет хоть как-то паралелить процесс дешифровки, хотя и является лютым костылем (но что поделать если gpg сам не умеет паралелиться).

FreeBSD ★★★ ()

Это не проблема

Это дизайн. man key stretching, scrypt, kbpdf.

DonkeyHot ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.