id: Гость   вход   регистрация
текущее время 12:27 10/07/2020
Автор темы: ressa, тема открыта 30/08/2014 23:45 Печать
Категории: софт, gnupg, исходные тексты
создать
просмотр
ссылки

Патчинг GnuPG

Вопрос правки исходников, с целью генерации 8192 битных ключей.
Скачал исходники последней версии GnuPG (2.0.26), решил пропатчить и собрать.
Все, как обычно: идем в /gnupg/g10, правим файл keygen.c:

Устанавливаем нужные либы, собираем. Все ок. Идем генерить ключ:

Отображает нужный мне предел длины ключа, отлично, вбиваю. Но тут возникает великий облом:

И он продолжает генерить 4096
Само собой – первое, что приходит на ум – это проверки. Беглое гугление не помогло, везде так указывается на правку указанной мной строки кода. Компилировал версии 1.4.18 и 2.0.26.
Буду признателен за помощь.


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— Гость (06/09/2014 13:45)   <#>

не сомневайтесь – проверено, а лучше сами попробуйте. делов-то на 30 минут.
— ressa (06/09/2014 14:05, исправлен 06/09/2014 20:31)   профиль/связь   <#>
комментариев: 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 – генерируется уже шесть часов, т.ч. походу бред.

— ressa (06/09/2014 21:58)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
Я уже не знаю, что делаю не так. Перерыл весь интернет и по мере своих каких-то логических мыслей – исходники. Не генерит он и все..
Вот, к примеру, последнее, что нашел. До этого делал так же, поправил еще файл gpg.c – тщетно.
I wanted to generate the RSA gnupg key with length of 16384 bits.
— Гость (07/09/2014 14:57)   <#>

сейчас проверил 0.3.2.1. да действительно не больше 16384. приношу извинение что обнадежил ((.
одно время меня тоже озаботил тот же вопрос, что и вас. ковырял разные программы и инструкции с инета, так вот отложилось в памяти что не было ограничений по длине. в какой из это получилось не помню (. идея генерации больших ключей была заброшена за не актуальностью и тратой много времени на генерацию.
комп придеться оставлять без присмотра (не сутками же сидеть рядом)... паранойя )
— ressa (07/09/2014 15:42, исправлен 07/09/2014 20:57)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59

Да ради Бога – мне любые знания важны, теперь зато точно не буду заблуждаться, к тому же – лишний раз в софте порылся. Правда так и не понял – почему он не генерирует у меня даже указанный размер.


Да у меня это уже спортивный интерес, чтобы самому найти, пропатчить, собрать. Для большинства этом мелочи, а для меня – маленький шаг в сторону освоения Linux. По поводу длинных ключей – ну да, пожалуй останусь на своем 8192, вот только GPG пропатчу. Unknown мне правильно говорил, что лучше использовать OpenSSL, который штатно поддерживает длинные ключи, я написал простой скрипт для автоматизации шифрования\дешифрования и у меня не так давно накрылись важные данные, т.к. он почему-то отказался дешифровывать, так что я все-таки добью GPG. В отказе дешифровки конечно мой косяк – что-то криво в скрипте написал, но вот рисковать больше так не хочу.
UPD
Господа, кто сталкивался и как бороться?
gpg: ВНИМАНИЕ: используется незащищенная память!
gpg: Для дополнительной информации см. http://www.gnupg.org/documentation/faqs.html


Точнее даже причины больше интересны. Спасибо

— Гость (08/09/2014 01:13)   <#>

Но вы же не выводите и даже не продляете. Признаюсь, давно не проверял, но пол года назад ещё было так. См. п. 1.
— SATtva (08/09/2014 10:08)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Чтоб меньше отвлекаться на болтовню в чятике. :)
— sentaus (08/09/2014 14:42)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32

gpg: ВНИМАНИЕ: используется незащищенная память!
gpg: Для дополнительной информации см. wwwhttp://www.gnupg.org/documentation/faqs.html


Это gpg пытается заблокировать память от возможного сброса в своп. Если свопа нет, то беспокоиться в общем-то не о чем. А если есть, то его надо шифровать. И разумеется, не пользоваться спящим режимом, когда ключ от свопа оказывается на диске.

Можно ещё выставить у gpg setuid, чтобы gpg стартовал с правами рута – это может быть небезопасно в некоторых случаях, но на практике на это вряд ли можно нарваться, я думаю.
Под Linux блокировка памяти возможно только если процесс запущен от рута, тогда будет гарантия со стороны ОС, что память не будет сброшена в своп.
Под Windows этого вроде вообще никак не сделать. По крайней мере, в gpg ничего для этого не реализовано.
— ressa (08/09/2014 15:16)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
sentaus Спасибо. Про спящий режим – в курсе, не пользуюсь. А вот про gpg – я в целом понял, но как бороться – нет, потому, что пробовал запускать sudo ./gpg --batch --gen-key – тоже самое.
— sentaus (08/09/2014 20:04, исправлен 08/09/2014 20:04)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
запускать sudo ... тоже самое.

Вот это странно, будет время, попробую и отпишусь.

— ressa (08/09/2014 20:53)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
sentaus
Без sudo:

С sudo:

К слову – сей вымышленный "имярек" – единственный пользователь в системе.
— sentaus (08/09/2014 22:28)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
А, ну это да. gnupg с sudo ведь от рута запущен, а владелец файла конфигурации – имярек.

Это сообщение будет вылезать всегда, когда пользователь, от которого gpg запущен, не равен владельцу файла конфигурации (для связок ключей тоже должно быть актуально). В общем случае это небезопасно, поскольку файл конфигурации может быть прочитан/изменён владельцем.

А с памятью всё в порядке становится.
— SATtva (09/09/2014 14:47)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Подавить предупреждение можно с помощью --no-permission-warning.
— ressa (09/09/2014 18:17, исправлен 09/09/2014 20:58)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59

sentaus, я так понял – просто скопировать конфиг в root? спасибо, испробую, может у меня и собралось все нормально и ключи длинные генерить смогу.


SATtva,

— unknown (09/09/2014 21:26)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Строго говоря, про 4-кратный экспоненциальный запас прочности — не совсем точно. Это только симметричный алгоритмы считаются неразличимыми от идеальных не быстрее брутфорса ключа, а иначе — теоретически взломанными. К сожалению, для асимметрики соблюдение таких строгих требований заведомо невозможно. Например, в контексте темы сложность целочисленной факторизации через GNFS хотя пока и остаётся в целом экспоненциальной, но с некоторыми поправками в степени. Иначе бы переход по доступности взлома 512→768→1024-битных ключей был бы вычислительно недостижим.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3