— SATtva (31/08/2014 10:00, исправлен 31/08/2014 10:01)   

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

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

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

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

— ressa (31/08/2014 15:23)   
Дам десятки тысяч упоминаний 4096..( Попробую погуглить еще.
Неужели никто не патчил?

— SATtva (31/08/2014 17:32)   
Никому не нужно. Потому что не нужно.

— unknown (31/08/2014 18:28)   
Майку Перри было нужно, что скатило ту ветку обсуждений его статьи^[link1] в частичный оффтопик про методики удлиннения ключа.

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

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

— SATtva (31/08/2014 18:39)   
Глядя на прогресс последних [десятков] лет, вторая точка зрения мне как-то ближе. И таки я всерьёз сомневаюсь, что увижу на своём веку практическую модель КК.


Майк Перри — тот ещё шифрпанк. :P

— Гость (04/09/2014 22:50)   

См. /comment71880^[link2].

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


А мне — первая. Если на современных ПК длина ключа мало на что влияет, то почему бы не удлинить... Хуже не будет, расходы минимальны, хотя да, кто-то может назвать такую практику самоуспокоением если не вообще карго-культом.

— ressa (05/09/2014 01:49)   

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

— Гость (05/09/2014 03:39)   

Уверены?


Это 4-кратный экспоненциальный запас прочности. Это в 2³⁰⁷² раз сложнее (или около того), чем 1024-битные ключи (которые пока ещё не умеют вроде как ломать, но скоро всё может быть). Возможно, брать 8192 и не следовало бы, глупость это, а я просто поддался эмоциям, примеру Майка и первым впечатлениям. С другой стороны, тех, кто упорно использует 1024-битные ключи, я тоже не понимаю.

— ressa (05/09/2014 04:15)   

Да я специально попробовал. Дело в том, что я нигде больше не сижу и этот случайный ник – тоже нигде не используется, как и любой другой. Но я некоторое время назад случайно наткнулся на OpenKeychain для Andorid и был приятно удивлен, что он дает возможность генерировать 8192, соответственно ничего умнее не придумал, как обкатать это на GPGRU. Тогда не получилось с нескольких попыток – пришлось сгенерить обычный.
Это да, но я не могу понять – почему в такой сфере, как криптография – казалось бы – как ЯО в масштабах сверхдержав – так категоричны к превентивным мерам? Ну т.е. даже на примере кратких предложений unknown на тему технократии о единовременном технологическом рывке. Ну что АНБ или ФСБ не имеет никаких секретных разработок? Да как-то мне с трудом верится, что у нас как и у них – все прозрачно и открыто.. Неужели столь мал шанс подобного рывка в масштабах страны под грифом "секретно"? Другой вопрос – да, я то точно им не нужен, тратить на меня время. Но опять таки – превентивные меры никто не отменял. Ну т.е. мне кажется, что здесь больше = лучше. Пусть и менее производительно.
У меня, возможно тупая аналогия, или черта такая.. Помню, в армии всегда кроме стандартной разгрузки – отжимал еще рожки и все-равно сматывал их изолентой, тем самым утраивая запас патронов.. Хотя прекрасно понимал, что не война, но неоднократно на учениях выручало – тяжелее по весу, но уверенность дает. Тоже самое и с финансами – лучше не просто меньше тратить, но еще и больше зарабатывать – разница растет очень заметно, опять таки – изматывая морально, физически и отнимая время, но результат на лицо. А тут – казалось бы, знающему человеку делов то – взять и пропатчить – это уж куда легче довешиваю свою разгрузку или спать по 3-4 часа, ведя параллельно несколько высокорисковых проектов..

— SATtva (05/09/2014 06:57)   

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


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


Сто раз обсуждалось: никаких из обнародованных секретных документов не дают оснований полагать, что они обладают какими-то прорывными научными преимуществами над открытым сообществом. Это не стопроцентное доказательство, но очень сильное косвенное свидетельство. Верить или не верить в это — дело Ваше. Вера, как известно, доказательств не требует.

— ressa (05/09/2014 10:41)   

Да не подгружался и все, ошибок точно никаких не было. А 4096 – сразу подцепился.
Я вот не помню, если честно в каких конкретно ситуациях – но было достаточно много приложений, которые "не видят" длинные ключи. По крайней мере полтора-два года назад – я вынуждено перешел обратно на 4096. Всякие особенно мобильные приложения. Потом с сервера не тянули и тд. Вот это все точно было.

— Гость (05/09/2014 10:58)   
есть приложение, которое генерит неограниченный размер ключа. проверено и работает.

— ressa (05/09/2014 13:58)   
Гость (05/09/2014 10:58), Будь добр – дай ссылку, пожалуйста. И, если можно – подробнее, о неограниченном размере ключа. Это конечно жесть, наверное, все, что больше 8192. Но ссылку дай – очень интересно. Спасибо.

— Гость (06/09/2014 00:03)   
пардон, только зашел.
здесь список билдов^[link3]. до 0.3.2 (вроде вкл) можно генерить ключи любово размера. затем можно просто брать файлы start_linux или start_windows из этих версий и копировать/копировать с изменением имени в более позднии билды.

— ressa (06/09/2014 02:46)   
Это старая тема, до версии 0.32 там была возможность генерить 8192. На счет "любого размера" – это я сомневаюсь)

— Гость (06/09/2014 13:45)   

не сомневайтесь – проверено, а лучше сами попробуйте. делов-то на 30 минут.

— ressa (06/09/2014 14:05, исправлен 06/09/2014 20:31)   

Если так – обязательно проверю. Версию конкретную не подскажешь, чтобы все не качать.
Знаю точно, что после указанной мной – ключи только 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)   
Я уже не знаю, что делаю не так. Перерыл весь интернет и по мере своих каких-то логических мыслей – исходники. Не генерит он и все..
Вот, к примеру, последнее, что нашел. До этого делал так же, поправил еще файл gpg.c – тщетно.
I wanted to generate the RSA gnupg key with length of 16384 bits.
Previously it was sufficient to increase the maximum key length: --- gnupg2-2.0.17.orig/g10/keygen.c +++ gnupg2-2.0.17/g10/keygen.c @@ -1774,7 +1774,7 @@ ask_algo (int addmode, int *r_subkey_alg static unsigned ask_keysize (int algo, unsigned int primary_keysize) { - unsigned int nbits, min, def = DEFAULT_STD_KEYSIZE, max=4096; + unsigned int nbits, min, def = DEFAULT_STD_KEYSIZE, max=16384; int for_subkey = !!primary_keysize; int autocomp = 0; Now it appears, that the above modification is not sufficient. Generation of key ends with out of memory error. To succesfully generate the 16k bit RSA key one needs to increase amount of allocated "secure memory": --- gnupg2-2.0.17.orig/g10/gpg.c +++ gnupg2-2.0.17/g10/gpg.c @@ -2050,7 +2050,7 @@ main (int argc, char **argv) #endif /* Initialize the secure memory. */ - if (!gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0)) + if (!gcry_control (GCRYCTL_INIT_SECMEM, 65536, 0)) got_secmem = 1; #if defined(HAVE_GETUID) && defined(HAVE_GETEUID) /* There should be no way to get to this spot while still carrying After above modifications I was able to successfully generate 16384 bits RSA key.

— Гость (07/09/2014 14:57)   

сейчас проверил 0.3.2.1. да действительно не больше 16384. приношу извинение что обнадежил ((.
одно время меня тоже озаботил тот же вопрос, что и вас. ковырял разные программы и инструкции с инета, так вот отложилось в памяти что не было ограничений по длине. в какой из это получилось не помню (. идея генерации больших ключей была заброшена за не актуальностью и тратой много времени на генерацию.
комп придеться оставлять без присмотра (не сутками же сидеть рядом)... паранойя )

— ressa (07/09/2014 15:42, исправлен 07/09/2014 20:57)   

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

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

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

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

Но вы же не выводите и даже не продляете. Признаюсь, давно не проверял, но пол года назад ещё было так. См. п. 1^[link4].

— sentaus (08/09/2014 14:42)   

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

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

Можно ещё выставить у gpg setuid, чтобы gpg стартовал с правами рута – это может быть небезопасно в некоторых случаях, но на практике на это вряд ли можно нарваться, я думаю.
Под Linux блокировка памяти возможно только если процесс запущен от рута, тогда будет гарантия со стороны ОС, что память не будет сброшена в своп.
Под Windows этого вроде вообще никак не сделать. По крайней мере, в gpg ничего для этого не реализовано.

— ressa (08/09/2014 15:16)   
sentaus Спасибо. Про спящий режим – в курсе, не пользуюсь. А вот про gpg – я в целом понял, но как бороться – нет, потому, что пробовал запускать sudo ./gpg --batch --gen-key – тоже самое.

— sentaus (08/09/2014 20:04, исправлен 08/09/2014 20:04)   

запускать sudo ... тоже самое.

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

— ressa (08/09/2014 20:53)   
sentaus
Без sudo:
/gnupg-1.4.18/g10 $ ./gpg --batch --gen-key gpg: ВНИМАНИЕ: используется незащищенная память! gpg: Для дополнительной информации см. http://www.gnupg.org/documentation/faqs.html
С sudo:
/gnupg-1.4.18/g10 $ sudo ./gpg --batch --gen-key [sudo] password for имярек: gpg: ВНИМАНИЕ: небезопасный владелец файла конфигурации `/home/имярек/.gnupg/gpg.conf'
К слову – сей вымышленный "имярек" – единственный пользователь в системе.

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

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

А с памятью всё в порядке становится.

— SATtva (09/09/2014 14:47)   
Подавить предупреждение можно с помощью --no-permission-warning.

— ressa (09/09/2014 18:17, исправлен 09/09/2014 20:58)   

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

SATtva,
./gpg --batch --gen-key --no-permission-warning gpg: ВНИМАНИЕ: используется незащищенная память! gpg: Для дополнительной информации см. http://www.gnupg.org/documentation/faqs.html

— unknown (09/09/2014 21:26)   

Строго говоря, про 4-кратный экспоненциальный запас прочности — не совсем точно. Это только симметричный алгоритмы считаются неразличимыми от идеальных не быстрее брутфорса ключа, а иначе — теоретически взломанными. К сожалению, для асимметрики соблюдение таких строгих требований заведомо невозможно. Например, в контексте темы сложность целочисленной факторизации^[link6] через GNFS^[link7] хотя пока и остаётся в целом экспоненциальной, но с некоторыми поправками в степени. Иначе бы переход по доступности взлома 512→768→1024-битных ключей был бы вычислительно недостижим.

— SATtva (10/09/2014 08:12)   
ressa, это был ответ на коммент sentaus'а по поводу sudo.

— sentaus (10/09/2014 14:00)   

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

Ничего не надо никуда копировать. В данном случае (один пользователь на машине) на предупреждение про владельца можно забить.

— ressa (10/09/2014 14:49)   
sentaus, ну так я забил, а дальше работа gpg то не идет. Просто курсор и все..

— Гость (11/09/2014 00:11)   
подтверждаю

— sentaus (11/09/2014 10:55)   

sentaus, ну так я забил, а дальше работа gpg то не идет. Просто курсор и все..

Подозреваю, что проблема в непонятно зачем включённом batch mode.

— ressa (13/09/2014 00:14)   
Вырубил batch mode, ошибок нет, но генерит все-равно 4096..

— Гость (13/09/2014 02:15)   
ну 16384 все равно больше 4096 )
имхо, свыше 10К уже комфортнее и время на создание не столько уходит.

— Гость (14/09/2014 14:52)   
Чтобы увеличить максимальную длину создаваемого ключа, нужно в файле g10/keygen.c заменить всюду 4096 на желаемое число. Если посмотреть код, то всего пять таких мест – строка перед генерацией (DEFAULT_STD_KEYSIZE) и два условных блока реально ограничивающих длину для ElGamal и RSA. Проверил для gpg2 – после замены 4096 на 8192 и компиляции действительно создаётся 8192-битный ключ. Возможно что для корректной работы нужны ещё правки, т.к. в других исходных файлах отводится память под переменные, видимо расчитывая на предел 4096. Если использовать слишком большой ключ, может какой-нибудь стек переполниться, но я так глубоко не рыл.

— Гость (16/09/2014 01:48)   
Мало кто знает, но длины ключей не обязаны быть кратными ни 1024, ни 4096, ни даже быть какой-либо степенью двойки. Вот^[link8] пример ключа с альтернативной длиной.

— Гость (16/09/2014 14:27)   
И что это даёт? Экзотическая длина ключа может служить как дополнительный различитель.

— ressa (09/12/2014 13:25)   
Господа, не могу проверить, т.к. нахожусь не у компа. Наткнулся вот^[link9] на что:
$ cat params.txt Key-Type: RSA Key-Length: 8192 Subkey-Type: RSA Subkey-Length: 8192 Name-Real: Tibor B**** Name-Email: tibor.b*****@gmail.com Creation-Date: 20150101T000000 Expire-Date: 20191231T000000 Passphrase: !!!change it!!! Preferences: S10 S9 S13 H10 Z3 Z2 Z1 %commit %echo done $ gpg --batch --gen-key params.txt
То есть – без всякого патчинга, на GPG любой версии можно смело генерить ключи указанной длинны?

— SATtva (09/12/2014 13:36)   
Нет, по крайней мере в ветке 2.0.x — в batch mode длина тоже ограничивается потолком 4096. Но, насколько помню, в каких-то прежних версиях такой трюк действительно работал.

— ressa (09/12/2014 14:13)   
Да к чему такой геммор? Почему не могут опционально сделать 8192? Ведь для чего-то такая длинна предусмотрена.. Старые версии хоть пропатчить можно было, а новые уже грепать устал..

— Гость (10/12/2014 02:21)   

Можно, но есть один нюанс:

В^[link10] текущем стабильном дебиане та версия GnuPG, где 8192 не задать в интерактиве, нужно batch mode использовать. Однако, в batch mode нельзя выбрать кастомные capabilites для главного ключа связки.

— Гость (01/02/2015 00:31)   
А чем все, собственно, закончилось?

— Гость (01/02/2015 00:39)   

Что именно?

— Гость (01/02/2015 16:16)   
Не догоняю, получается ли генерить ключи длинной 8192.

— Гость (01/02/2015 18:07)   
Зависит от версии GnuPG. Кое-где получается, но только в batch mode, поэтому произвольный ключ не создашь. В иных версиях можно искоробки генерить такие, всё стандартно.

— Гость (01/02/2015 20:16)   

Получается.

— ressa (02/02/2015 12:49)   
В старых версиях можно. Патчишь и собираешь. Там одну строку изменить, как в первом посте я писал. А вот в новых – у меня не получилось. Готов присоединиться, если будут желающие поковырять.

— Yellow (18/06/2015 17:22)   
Голова идет кругом от избытка информации. Будьте добры, кто-либо, ткните носом в последовательность действий для генерации ключей длинной 8192 бит в старых GPG. Требуется потом использовать их в Thunderbird+Enigmail.

Достаточно просто тупо указать последовательность действий, а как это конкретно сделать разберусь сам. Спасибо.

— Yellow (19/06/2015 11:59)   

"Патчить" означает "строку изменить"?

— pgprubot (19/06/2015 11:59, исправлен 19/06/2015 12:05)   

Проще всего ничего не патчить и не устанавливать новые версии, а воспользоваться этим^[link11] способом. Правда, у него есть ограничения, из-за которых он может вам не подойти. В частности, нельзя сделать главный ключ только сертифицирующим (будет ещё sign-капабилити), и можно будет повесить на связку только один подключ. Т.е. будет главный ключ длиной 8192 бит и один подключ такой же длины. Навесить ещё подключи потом будет можно, но уже только со стандартными длинами, допускаемыми интерактивом (не более 4096 бит).

P.S. Вы хотите неправильного. Если взвесить все пока что известные факты, «за» и «против», то можно прийти к выводу, что ключей в 4096 бит достаточно с лихвой. В перспективе, думаю, всё равно все перейдут на эллиптику (Tor, SSH и TLS, в общем-то, уже это сделали).

«Патчить» дословно означает «применить patch» (см. man patch^[link12]). Применение патча меняет код (обычно исходный). В частном случае изменение может коснуться только одной строки, что проще сделать руками, чем автоматическим применением патча, однако, такие изменения кода всё равно называют его патчением.

— Yellow (19/06/2015 13:27, исправлен 19/06/2015 13:28)   

Прочитал это^[link11], действую так^[link13]. Получается генерить ключи бОльшего размера. Но странно, что только до 5440 бит. Больше не дает, пишет

gpg: out of secure memory while allocating xxxx bytes gpg: (this may be caused by too many secret keys / used simultaneously or due to excessive large key sizes)

Мало RAM, что ли?

— SATtva (19/06/2015 13:34)   
Для криптографических операций GnuPG выделяет небольшую область памяти со специальными свойствами, в частности, не даёт ОС выгружать её в своп. Предельный объём такой памяти захардкоден в исходниках.

— Yellow (19/06/2015 13:41, исправлен 19/06/2015 13:42)   

Размер предельного объема захардкорен процентуально от объема RAM? Захардкорен в исходниках GnuPG?

— SATtva (19/06/2015 13:46)   
Объём ОЗУ вообще не при чём, размер такой защищённой памяти — сотни байт.


Да.

— Yellow (19/06/2015 13:51)   
Извините за, возможно, глупый вопрос. А как тогда люди получают ключи 8192 или 16384 бит? У меня что – особенная версия GnuPG 1.4.12, в которой этого не сделать? :-)

— SATtva (19/06/2015 14:20)   
Понятия не имею. Честно говоря, Вы вообще занимаетесь ерундой, о чём Вам ранее уже сказали^[link14].

— Yellow (19/06/2015 14:40)   
Короче, уяснил для себя, что есть два способа, как получить бОльшие ключи в GPG:

1. с параметром --batch (учитывая различные ограничения)
2. собрать GPG из правленных исходников

И мне понятно, как действовать в обоих случаях, т.е. я получил ответы на свои вопросы.

Всем большое спасибо.

PS. Может кому понадобится по теме раз^[link15] два^[link16] три^[link17].

— pgprubot (19/06/2015 14:40, исправлен 19/06/2015 15:05)   

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

Неадекватно большие длины ключей — это, скорее, просто понты людей плохо разбирающихся в ИБ, чем нечто полезное. Они идут в один ряд с такими заморочками, как каскадное шифрование. Это попытка усиления и так самого стойкого звена в защите (причём зачастую наивная и бездоказательная). Симптоматично, что неадекватные длины ключей упомянуты одним из признаков ханаанского бальзама (см. №5^[link18]).

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

Учтите, что там патчи под конкретные версии. Применять их к иным версиям надо творчески и внимательно, а не вслепую.

Насколько я помню старые обсуждения, в самых новых версиях ограничения в 4096 бит для интерактивного режима нет, поэтому есть третий способ (более правильный, чем патчи): установить более свежую версию GnuPG. Как это сделать — уже вопрос третий, зависит от специфики ОС.

— Yellow (19/06/2015 15:22)   
Уверяю Вас, что с большим уважением и благодарностью отношусь к тому, что Вы и другие знающие люди тратите неимоверное количество времени на таких, как я. :-)

Мне понятно, что "ненормально" большие ключи с точки зрения криптографии – ханаанское излишество. :-) Но у меня есть практические причины (т.е. не в плоскости криптографии самой по себе) хотеть использовать максимально доступную длину ключа.

Кроме этого, задача просто показалась интересной. В процессе изучения вопроса познакомился с большим количеством смежной инфы. Т.е. такая, как бы, глупость (сделать дурацкие ключи и радостно воткнуть их себе в Thunderbird) подтолкнула к получению новых существенных и разнообразных знаний.

Более того, поскольку мне самому все это очень интересно (и в теории, и в практике), пытаюсь подсадить на тему людей из своего окружения. Они тоже сейчас сядут и будут генерить неконфекционные ключи, т.к. им это просто интересно. А чем интересней будет, тем больше людей будут хотеть заниматься вопросами ИБ.

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

Еще раз спасибо.

— pgprubot (19/06/2015 16:03, исправлен 19/06/2015 16:11)   

Неужели похвастаться перед девочками «а у меня ключ длинее, чем у всех!» ? :) Можно ещё кастомные отпечатки брутфорсить, тоже понт.

Помню случай, как один человек много лет назад хвастался, что он сгенерил ключ то ли на 8192 бит, то ли на 16384... Это не мешало ему как попало относиться к ИБ, терять приватные ключи десятками и заспамливать этими ключами публичные серверы ключей.

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

Если вам так хочется углубиться, есть же куда более полезные занятия в рамках GnuPG, которые действительно увеличивают безопасность:

1. Разобраться с capabilities и выставлять их на ключах правильно (дефолты в GnuPG не всем типам нужд хорошо соответствуют).
2. Разобраться с предпочтениями алгоритмов и выбрать их разумным образом (дефолты в GnuPG плохие).
3. Научиться хранить главный ключ связки отдельно от подключей на внешнем носителе, чтобы защититься от компрометации (настоятельно рекомендуется так делать).
4. Разобраться с notations для PGP-ключей (uid'ов), научиться вешать на ключ нужную информацию (например, детали контактов для связи).
5. Разобраться с заверением чужих ключей своим, с разными видами подписей, сертификаций, сессиями заверителей и участием в сети доверия.
6. Разобраться с отзывом ключей и подключей, с ротацией подключей, с сертификатами отзыва и ключом с правом отзыва (revoker).
7. Установить и настроить gpg-remote, чтобы в случае компрометации профиля противник не мог похитить ключ.
8. (Понты) Научиться добавлять главный ключ на связку другого ключа (в качестве подключа) и потом отзывать этот главный ключ.

Видите, какое большое поле деятельности? Вы всё из этого знаете/умеете? Всё вышеперечисленное будет более полезным для ИБ, чем поиск методов удлиннить член ключ. Главное — не длинна, а умение владеть инструментом. Перечисленные пункты как раз относятся к категории владения.

— Yellow (19/06/2015 16:42, исправлен 19/06/2015 16:42)   

Скорее, перед взрослыми тетями. :-)

Учту

— Yellow (21/06/2015 13:34)   

Будьте добры, для чего это может понадобиться?

— pgprubot (21/06/2015 19:43, исправлен 21/06/2015 19:47)   

Речь шла об этом^[link19]. С учётом данных^[link20] замечаний штатно это не сделать, придётся писать свой код под эту задачу.

Как я понимаю, в OpenPGP не предусмотрены штатные механизмы полной смены ключа. Можно написать анонс о смене ключа, подписать его старым ключом и повесить где-то на видном месте. Можно добавить keyid/отпечаток нового ключа (и какую дуругую информацию) в uid'ы старого, после чего отозвать старый ключ. Можно эту информацию добавить не в uid'ы, а в uid notations. Можно назначить новый ключ revoker'ом старого, после чего отозвать старый ключ новым ключом. Методы не исключают друг друга, их можно комбинировать.

Ещё один из вариантов — перенести старый ключ на новую связку, чтобы все штатно видели, что то был ваш старый ключ или подключ. Если тем ключом что-то было подписано или зашифровано, вы сможете расшифровывать (или сверять подписи) новым ключом. Правда, если шифровалось или подписывалось подключами, то это не сработает. Можно, наверно, по аналогии попытаться перенести на новую связку как главный ключ, так и подключи, тогда должно заработать всё, но как это будет дружить с GnuPG и к каким потенциальным проблемам приведёт — непонятно. Во всяком случае, если это заработает, оно даст некоторые интересные возможности, у которых могут быть полезные на практике применения.

— Yellow (21/06/2015 20:06)   
Понял, спасибо.

— SATtva (22/06/2015 07:27, исправлен 22/06/2015 07:28)   

По-моему, Вы тут используете неконвенциональную терминологию. Связкой в рамках OpenPGP-реализаций принято называть базу данных различных OpenPGP-ключей (сертификатов). Если Вы имеете в виду базовый ключ с подключами, то это не связка, а просто OpenPGP-ключ или сертификат.

Уточняю, чтобы не было путаницы.

— pgprubot (22/06/2015 10:20)   

Да, именно так. Спасибо за поправку, почему-то всегда так считал. Когда говорят «главный ключ» или «подключ», всё понятно, но иногда нужно сослаться на сущность «главный ключ + его подключи» (собственно, это и есть «полный» OpenPGP-ключ). Получается, что эта сущность называется просто «ключом» (без уточнений), поэтому в некоторых контекстах может быть ошибочно интерпретирована как «только главный ключ». Слово «сертификат» применительно к OpenPGP вообще первый раз слышу.