Патчинг GnuPG
Вопрос правки исходников, с целью генерации 8192 битных ключей.
Скачал исходники последней версии GnuPG (2.0.26), решил пропатчить и собрать.
Все, как обычно: идем в /gnupg/g10, правим файл keygen.c:
Устанавливаем нужные либы, собираем. Все ок. Идем генерить ключ:
Отображает нужный мне предел длины ключа, отлично, вбиваю. Но тут возникает великий облом:
И он продолжает генерить 4096
Само собой – первое, что приходит на ум – это проверки. Беглое гугление не помогло, везде так указывается на правку указанной мной строки кода. Компилировал версии 1.4.18 и 2.0.26.
Буду признателен за помощь.
не сомневайтесь – проверено, а лучше сами попробуйте. делов-то на 30 минут.
комментариев: 1079 документов: 58 редакций: 59
Если так – обязательно проверю. Версию конкретную не подскажешь, чтобы все не качать.
Знаю точно, что после указанной мной – ключи только 4096. Я, кстати и хочу пропатчить GPG, чтобы закинуть его в /bin рядом с gpg4usb – новая альфа его многообещающая. Сам gpg4usb пропатчил, могу бинарник альфы последней выложить, а вот gpg – все никак..(
UPD
gpg4usb-0.3.2 – не более 16384
gpg4usb-0.3.0 – не более 8192
gpg4usb-0.2.5 – не более 8192
gpg4usb-0.2.4 – не более 8192
gpg4usb-0.2.3 – не более 8192
gpg4usb-0.2 – не более 8192
Дальше лень было качать. Заморочился именно из за "любой" длинны ключа. Я думал, что больше 8192 или 16384 быть не может.
UPD2
16384 – генерируется уже шесть часов, т.ч. походу бред.
комментариев: 1079 документов: 58 редакций: 59
Вот, к примеру, последнее, что нашел. До этого делал так же, поправил еще файл gpg.c – тщетно.
I wanted to generate the RSA gnupg key with length of 16384 bits.
сейчас проверил 0.3.2.1. да действительно не больше 16384. приношу извинение что обнадежил ((.
одно время меня тоже озаботил тот же вопрос, что и вас. ковырял разные программы и инструкции с инета, так вот отложилось в памяти что не было ограничений по длине. в какой из это получилось не помню (. идея генерации больших ключей была заброшена за не актуальностью и тратой много времени на генерацию.
комп придеться оставлять без присмотра (не сутками же сидеть рядом)... паранойя )
комментариев: 1079 документов: 58 редакций: 59
Да ради Бога – мне любые знания важны, теперь зато точно не буду заблуждаться, к тому же – лишний раз в софте порылся. Правда так и не понял – почему он не генерирует у меня даже указанный размер.
Да у меня это уже спортивный интерес, чтобы самому найти, пропатчить, собрать. Для большинства этом мелочи, а для меня – маленький шаг в сторону освоения Linux. По поводу длинных ключей – ну да, пожалуй останусь на своем 8192, вот только GPG пропатчу. Unknown мне правильно говорил, что лучше использовать OpenSSL, который штатно поддерживает длинные ключи, я написал простой скрипт для автоматизации шифрования\дешифрования и у меня не так давно накрылись важные данные, т.к. он почему-то отказался дешифровывать, так что я все-таки добью GPG. В отказе дешифровки конечно мой косяк – что-то криво в скрипте написал, но вот рисковать больше так не хочу.
UPD
Господа, кто сталкивался и как бороться?
gpg: ВНИМАНИЕ: используется незащищенная память!
gpg: Для дополнительной информации см. http://www.gnupg.org/documentation/faqs.html
Точнее даже причины больше интересны. Спасибо
Но вы же не выводите
и даже не продляете. Признаюсь, давно не проверял, но пол года назад ещё было так. См. п. 1.комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 1060 документов: 16 редакций: 32
Это gpg пытается заблокировать память от возможного сброса в своп. Если свопа нет, то беспокоиться в общем-то не о чем. А если есть, то его надо шифровать. И разумеется, не пользоваться спящим режимом, когда ключ от свопа оказывается на диске.
Можно ещё выставить у gpg setuid, чтобы gpg стартовал с правами рута – это может быть небезопасно в некоторых случаях, но на практике на это вряд ли можно нарваться, я думаю.
Под Linux блокировка памяти возможно только если процесс запущен от рута, тогда будет гарантия со стороны ОС, что память не будет сброшена в своп.
Под Windows этого вроде вообще никак не сделать. По крайней мере, в gpg ничего для этого не реализовано.
комментариев: 1079 документов: 58 редакций: 59
комментариев: 1060 документов: 16 редакций: 32
Вот это странно, будет время, попробую и отпишусь.
комментариев: 1079 документов: 58 редакций: 59
Без sudo:
С sudo:
К слову – сей вымышленный "имярек" – единственный пользователь в системе.
комментариев: 1060 документов: 16 редакций: 32
Это сообщение будет вылезать всегда, когда пользователь, от которого gpg запущен, не равен владельцу файла конфигурации (для связок ключей тоже должно быть актуально). В общем случае это небезопасно, поскольку файл конфигурации может быть прочитан/изменён владельцем.
А с памятью всё в порядке становится.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 1079 документов: 58 редакций: 59
sentaus, я так понял – просто скопировать конфиг в root? спасибо, испробую, может у меня и собралось все нормально и ключи длинные генерить смогу.
SATtva,
комментариев: 9796 документов: 488 редакций: 5664
Строго говоря, про 4-кратный экспоненциальный запас прочности — не совсем точно. Это только симметричный алгоритмы считаются неразличимыми от идеальных не быстрее брутфорса ключа, а иначе — теоретически взломанными. К сожалению, для асимметрики соблюдение таких строгих требований заведомо невозможно. Например, в контексте темы сложность целочисленной факторизации через GNFS хотя пока и остаётся в целом экспоненциальной, но с некоторыми поправками в степени. Иначе бы переход по доступности взлома 512→768→1024-битных ключей был бы вычислительно недостижим.