id: Гость   вход   регистрация
текущее время 23:29 24/11/2017
Автор темы: 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 След.
Комментарии
— SATtva (31/08/2014 10:00, исправлен 31/08/2014 10:01)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Грепайте исходники на предмет других упоминаний 4096. И следует иметь в виду, что функции управления ключами в gpg 2.x постепенно выносят в gpg-agent, так что стоит погрепать и его.


Из оффтопичной ветки:


Потому что не Вы определяете, какая производительность у девайса Вашего корреспондента, т.е. своё решение по длине ключа Вы перекладываете на него в виде длительных криптоопераций и разряженной батареи.



Ни я, ни скорее всего даже Вы не доживём до того момента, когда хотя бы 4096-битовые ключи будут так в лёгкую ломать (если вообще смогут), так что забейте.

— ressa (31/08/2014 15:23)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
Дам десятки тысяч упоминаний 4096..( Попробую погуглить еще.
Неужели никто не патчил?
— SATtva (31/08/2014 17:32)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046
Никому не нужно. Потому что не нужно.
— unknown (31/08/2014 18:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Майку Перри было нужно, что скатило ту ветку обсуждений его статьи в частичный оффтопик про методики удлиннения ключа.

Есть несколько спекулятивных мнений на этот счёт. Одно из них — мнение Шнайера. Он ещё в книге «Практическая криптография» (не путать с его более старой и знаменитой «прикладной») советовал выбирать как можно более длинные асимметричные ключи, если практические ограничения этому не мешают, опасаясь прогресса в изобретении новых методов взлома асимметрики. Он вообще несколько парадоксально считает, что симметрика надёжнее, несмотря на худшую доказуемость. И в той книге он вбросил про 16-килобитные RSA-ключи.

Другая точка зрения, дополняющая первую, состоит в том, что если мы настолько не уверены в своих оценках будущей стойкости асимметрики, то не факт, что метод резкого увеличения способности к взлому ключей не окажется вообще фатальным для существующей асимметрики. Это такой тоже парадоксальный оптимистичный пессимизм, или пофигизм проще говоря (бесполезно так мелко дёргаться, если всё будет совсем глобально плохо).
— SATtva (31/08/2014 18:39)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046
Глядя на прогресс последних [десятков] лет, вторая точка зрения мне как-то ближе. И таки я всерьёз сомневаюсь, что увижу на своём веку практическую модель КК.


Майк Перри — тот ещё шифрпанк. :P
— Гость (04/09/2014 22:50)   <#>

См. /comment71880.

В текущем стабильном дебиане та версия GnuPG, где 8192 не задать в интерактиве, нужно batch mode использовать. Однако, в batch mode нельзя выбрать кастомные capabilites для главного ключа связки. Получается, в текущей версии GnuPG 8192 по-нормальному не выбрать никак. Если принципиально, я бы посоветовал не патчить, а установить более свежий GnuPG. Лично для себя, если честно, я решил забить. Довольствуюсь 4096-битными RSA.


А мне — первая. Если на современных ПК длина ключа мало на что влияет, то почему бы не удлинить... Хуже не будет, расходы минимальны, хотя да, кто-то может назвать такую практику самоуспокоением если не вообще карго-культом.
— ressa (05/09/2014 01:49)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59

Ну вот это мне точно не годиться, и в тоже время я солидарен с мнением SATtva, понимая, что лично мной никто целенаправленно заниматься не будет, и как он правильно сказал – даже при выделении всех ресурсов взлом затянется на долго. Просто как раз твои слова у меня в голове ассоциируются с каким-то смирением, что собственно ни в чем для меня не свойственно. Опять таки – мои меры использования криптографии нацелены только на личные интересы, которые на столько ничтожны в масштабе попадания под, как здесь некоторые выражаются – "их" внимание – очень маловероятен. Но для меня всегда был принцип – лучше больше, чем меньше, в здравых пределах, как я недавно услышал выражение "лучше перебдить, чем недобдить", кто его знает, что в будущем будут – объявят врагом народа и начнут из пальца высасывать. А с 8192-м ключом – пусть хоть из собственных х@ев высасывают..Кстати, твой совет по поводу использования длинных ключей в OpenSSL, потому ,что он, как ты сказал – поддерживает их штатно – я помню, вот только переписку шифровать все-же GPG нужно, но для OpenSSL с его длинными ключами я тоже определил место – я файлы им шифрую, и даже некоторые криптоконтейнеры, как бы параноидально это ни было) С моим "уровнем" знаний – лучше лишний раз перестраховаться, а тем, кто действительно понимает суть вещей, как те же вы с SATva и те самые несколько Гостей – конечно проще 4096 шифровать, потому, что уверены в своей правоте. Мне же, чем больше – тем лучше и спокойнее.
Да я устанавливал – не получалос сгенерить и в режиме эксперта – тоже. Я раньше компилировал GnuPG и получалось генерить 8291, а сейчас несколько версий перебрал – тщетно. Видимо где-то еще проверки есть.. А совет SATva может кому-то и расплюнуть, но для меня это недельный труд, и не факт, что смогу найти..
Ну вот да, потому, что уровень знаний высок, поэтому и уверенность. У меня же наоборот.
Взаимоисключающие, уважаемый))
[offtop]
Кстати, SATtva. Движок твой 8192 не принимает, понимаю, что они не нужны, но тем не менее – мало ли, не знал.
[/offtop]
— Гость (05/09/2014 03:39)   <#>

Уверены?


Это 4-кратный экспоненциальный запас прочности. Это в 23072 раз сложнее (или около того), чем 1024-битные ключи (которые пока ещё не умеют вроде как ломать, но скоро всё может быть). Возможно, брать 8192 и не следовало бы, глупость это, а я просто поддался эмоциям, примеру Майка и первым впечатлениям. С другой стороны, тех, кто упорно использует 1024-битные ключи, я тоже не понимаю.
— ressa (05/09/2014 04:15)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59

Да я специально попробовал. Дело в том, что я нигде больше не сижу и этот случайный ник – тоже нигде не используется, как и любой другой. Но я некоторое время назад случайно наткнулся на OpenKeychain для Andorid и был приятно удивлен, что он дает возможность генерировать 8192, соответственно ничего умнее не придумал, как обкатать это на GPGRU. Тогда не получилось с нескольких попыток – пришлось сгенерить обычный.
Это да, но я не могу понять – почему в такой сфере, как криптография – казалось бы – как ЯО в масштабах сверхдержав – так категоричны к превентивным мерам? Ну т.е. даже на примере кратких предложений unknown на тему технократии о единовременном технологическом рывке. Ну что АНБ или ФСБ не имеет никаких секретных разработок? Да как-то мне с трудом верится, что у нас как и у них – все прозрачно и открыто.. Неужели столь мал шанс подобного рывка в масштабах страны под грифом "секретно"? Другой вопрос – да, я то точно им не нужен, тратить на меня время. Но опять таки – превентивные меры никто не отменял. Ну т.е. мне кажется, что здесь больше = лучше. Пусть и менее производительно.
У меня, возможно тупая аналогия, или черта такая.. Помню, в армии всегда кроме стандартной разгрузки – отжимал еще рожки и все-равно сматывал их изолентой, тем самым утраивая запас патронов.. Хотя прекрасно понимал, что не война, но неоднократно на учениях выручало – тяжелее по весу, но уверенность дает. Тоже самое и с финансами – лучше не просто меньше тратить, но еще и больше зарабатывать – разница растет очень заметно, опять таки – изматывая морально, физически и отнимая время, но результат на лицо. А тут – казалось бы, знающему человеку делов то – взять и пропатчить – это уж куда легче довешиваю свою разгрузку или спать по 3-4 часа, ведя параллельно несколько высокорисковых проектов..
— SATtva (05/09/2014 06:57)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

В чём это выражалось? Никаких проверок на длину ключа не осуществляется, а сами операции выполняет gpg, которому на длину должно быть пофиг.


Их даже NIST настойчиво советует выводить из обращения.


Сто раз обсуждалось: никаких из обнародованных секретных документов не дают оснований полагать, что они обладают какими-то прорывными научными преимуществами над открытым сообществом. Это не стопроцентное доказательство, но очень сильное косвенное свидетельство. Верить или не верить в это — дело Ваше. Вера, как известно, доказательств не требует.
— ressa (05/09/2014 10:41)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59

Да не подгружался и все, ошибок точно никаких не было. А 4096 – сразу подцепился.
Я вот не помню, если честно в каких конкретно ситуациях – но было достаточно много приложений, которые "не видят" длинные ключи. По крайней мере полтора-два года назад – я вынуждено перешел обратно на 4096. Всякие особенно мобильные приложения. Потом с сервера не тянули и тд. Вот это все точно было.
— Гость (05/09/2014 10:58)   <#>
есть приложение, которое генерит неограниченный размер ключа. проверено и работает.
— ressa (05/09/2014 13:58)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
Гость (05/09/2014 10:58), Будь добр – дай ссылку, пожалуйста. И, если можно – подробнее, о неограниченном размере ключа. Это конечно жесть, наверное, все, что больше 8192. Но ссылку дай – очень интересно. Спасибо.
— Гость (06/09/2014 00:03)   <#>
пардон, только зашел.
здесь список билдов. до 0.3.2 (вроде вкл) можно генерить ключи любово размера. затем можно просто брать файлы start_linux или start_windows из этих версий и копировать/копировать с изменением имени в более позднии билды.
— ressa (06/09/2014 02:46)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
Это старая тема, до версии 0.32 там была возможность генерить 8192. На счет "любого размера" – это я сомневаюсь)
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3