Патчинг GnuPG
Вопрос правки исходников, с целью генерации 8192 битных ключей.
Скачал исходники последней версии GnuPG (2.0.26), решил пропатчить и собрать.
Все, как обычно: идем в /gnupg/g10, правим файл keygen.c:
Устанавливаем нужные либы, собираем. Все ок. Идем генерить ключ:
Отображает нужный мне предел длины ключа, отлично, вбиваю. Но тут возникает великий облом:
И он продолжает генерить 4096
Само собой – первое, что приходит на ум – это проверки. Беглое гугление не помогло, везде так указывается на правку указанной мной строки кода. Компилировал версии 1.4.18 и 2.0.26.
Буду признателен за помощь.
комментариев: 11558 документов: 1036 редакций: 4118
Грепайте исходники на предмет других упоминаний 4096. И следует иметь в виду, что функции управления ключами в gpg 2.x постепенно выносят в gpg-agent, так что стоит погрепать и его.
Из оффтопичной ветки:
Потому что не Вы определяете, какая производительность у девайса Вашего корреспондента, т.е. своё решение по длине ключа Вы перекладываете на него в виде длительных криптоопераций и разряженной батареи.
Ни я, ни скорее всего даже Вы не доживём до того момента, когда хотя бы 4096-битовые ключи будут так в лёгкую ломать (если вообще смогут), так что забейте.
комментариев: 1079 документов: 58 редакций: 59
Неужели никто не патчил?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Есть несколько спекулятивных мнений на этот счёт. Одно из них — мнение Шнайера. Он ещё в книге «Практическая криптография» (не путать с его более старой и знаменитой «прикладной») советовал выбирать как можно более длинные асимметричные ключи, если практические ограничения этому не мешают, опасаясь прогресса в изобретении новых методов взлома асимметрики. Он вообще несколько парадоксально считает, что симметрика надёжнее, несмотря на худшую доказуемость. И в той книге он вбросил про 16-килобитные RSA-ключи.
Другая точка зрения, дополняющая первую, состоит в том, что если мы настолько не уверены в своих оценках будущей стойкости асимметрики, то не факт, что метод резкого увеличения способности к взлому ключей не окажется вообще фатальным для существующей асимметрики. Это такой тоже парадоксальный оптимистичный пессимизм, или пофигизм проще говоря (бесполезно так мелко дёргаться, если всё будет совсем глобально плохо).
комментариев: 11558 документов: 1036 редакций: 4118
Майк Перри — тот ещё шифрпанк. :P
См. /comment71880.
В текущем стабильном дебиане та версия GnuPG, где 8192 не задать в интерактиве, нужно batch mode использовать. Однако, в batch mode нельзя выбрать кастомные capabilites для главного ключа связки. Получается, в текущей версии GnuPG 8192 по-нормальному не выбрать никак. Если принципиально, я бы посоветовал не патчить, а установить более свежий GnuPG. Лично для себя, если честно, я решил забить. Довольствуюсь 4096-битными RSA.
А мне — первая. Если на современных ПК длина ключа мало на что влияет, то почему бы не удлинить... Хуже не будет, расходы минимальны, хотя да, кто-то может назвать такую практику самоуспокоением если не вообще карго-культом.
комментариев: 1079 документов: 58 редакций: 59
Ну вот это мне точно не годиться, и в тоже время я солидарен с мнением SATtva, понимая, что лично мной никто целенаправленно заниматься не будет, и как он правильно сказал – даже при выделении всех ресурсов взлом затянется на долго. Просто как раз твои слова у меня в голове ассоциируются с каким-то смирением, что собственно ни в чем для меня не свойственно. Опять таки – мои меры использования криптографии нацелены только на личные интересы, которые на столько ничтожны в масштабе попадания под, как здесь некоторые выражаются – "их" внимание – очень маловероятен. Но для меня всегда был принцип – лучше больше, чем меньше, в здравых пределах, как я недавно услышал выражение "лучше перебдить, чем недобдить", кто его знает, что в будущем будут – объявят врагом народа и начнут из пальца высасывать. А с 8192-м ключом – пусть хоть из собственных х@ев высасывают..Кстати, твой совет по поводу использования длинных ключей в OpenSSL, потому ,что он, как ты сказал – поддерживает их штатно – я помню, вот только переписку шифровать все-же GPG нужно, но для OpenSSL с его длинными ключами я тоже определил место – я файлы им шифрую, и даже некоторые криптоконтейнеры, как бы параноидально это ни было) С моим "уровнем" знаний – лучше лишний раз перестраховаться, а тем, кто действительно понимает суть вещей, как те же вы с SATva и те самые несколько Гостей – конечно проще 4096 шифровать, потому, что уверены в своей правоте. Мне же, чем больше – тем лучше и спокойнее.
Да я устанавливал – не получалос сгенерить и в режиме эксперта – тоже. Я раньше компилировал GnuPG и получалось генерить 8291, а сейчас несколько версий перебрал – тщетно. Видимо где-то еще проверки есть.. А совет SATva может кому-то и расплюнуть, но для меня это недельный труд, и не факт, что смогу найти..
Ну вот да, потому, что уровень знаний высок, поэтому и уверенность. У меня же наоборот.
Взаимоисключающие, уважаемый))
[offtop]
Кстати, SATtva. Движок твой 8192 не принимает, понимаю, что они не нужны, но тем не менее – мало ли, не знал.
[/offtop]
Уверены?
Это 4-кратный экспоненциальный запас прочности. Это в 23072 раз сложнее (или около того), чем 1024-битные ключи (которые пока ещё не умеют вроде как ломать, но скоро всё может быть). Возможно, брать 8192 и не следовало бы, глупость это, а я просто поддался эмоциям, примеру Майка и первым впечатлениям. С другой стороны, тех, кто упорно использует 1024-битные ключи, я тоже не понимаю.
комментариев: 1079 документов: 58 редакций: 59
Да я специально попробовал. Дело в том, что я нигде больше не сижу и этот случайный ник – тоже нигде не используется, как и любой другой. Но я некоторое время назад случайно наткнулся на OpenKeychain для Andorid и был приятно удивлен, что он дает возможность генерировать 8192, соответственно ничего умнее не придумал, как обкатать это на GPGRU. Тогда не получилось с нескольких попыток – пришлось сгенерить обычный.
Это да, но я не могу понять – почему в такой сфере, как криптография – казалось бы – как ЯО в масштабах сверхдержав – так категоричны к превентивным мерам? Ну т.е. даже на примере кратких предложений unknown на тему технократии о единовременном технологическом рывке. Ну что АНБ или ФСБ не имеет никаких секретных разработок? Да как-то мне с трудом верится, что у нас как и у них – все прозрачно и открыто.. Неужели столь мал шанс подобного рывка в масштабах страны под грифом "секретно"? Другой вопрос – да, я то точно им не нужен, тратить на меня время. Но опять таки – превентивные меры никто не отменял. Ну т.е. мне кажется, что здесь больше = лучше. Пусть и менее производительно.
У меня, возможно тупая аналогия, или черта такая.. Помню, в армии всегда кроме стандартной разгрузки – отжимал еще рожки и все-равно сматывал их изолентой, тем самым утраивая запас патронов.. Хотя прекрасно понимал, что не война, но неоднократно на учениях выручало – тяжелее по весу, но уверенность дает. Тоже самое и с финансами – лучше не просто меньше тратить, но еще и больше зарабатывать – разница растет очень заметно, опять таки – изматывая морально, физически и отнимая время, но результат на лицо. А тут – казалось бы, знающему человеку делов то – взять и пропатчить – это уж куда легче довешиваю свою разгрузку или спать по 3-4 часа, ведя параллельно несколько высокорисковых проектов..
комментариев: 11558 документов: 1036 редакций: 4118
В чём это выражалось? Никаких проверок на длину ключа не осуществляется, а сами операции выполняет gpg, которому на длину должно быть пофиг.
Их даже NIST настойчиво советует выводить из обращения.
Сто раз обсуждалось: никаких из обнародованных секретных документов не дают оснований полагать, что они обладают какими-то прорывными научными преимуществами над открытым сообществом. Это не стопроцентное доказательство, но очень сильное косвенное свидетельство. Верить или не верить в это — дело Ваше. Вера, как известно, доказательств не требует.
комментариев: 1079 документов: 58 редакций: 59
Да не подгружался и все, ошибок точно никаких не было. А 4096 – сразу подцепился.
Я вот не помню, если честно в каких конкретно ситуациях – но было достаточно много приложений, которые "не видят" длинные ключи. По крайней мере полтора-два года назад – я вынуждено перешел обратно на 4096. Всякие особенно мобильные приложения. Потом с сервера не тянули и тд. Вот это все точно было.
комментариев: 1079 документов: 58 редакций: 59
здесь список билдов. до 0.3.2 (вроде вкл) можно генерить ключи любово размера. затем можно просто брать файлы start_linux или start_windows из этих версий и копировать/копировать с изменением имени в более позднии билды.
комментариев: 1079 документов: 58 редакций: 59