06.11 // Релиз GnuPG 2.1.0 modern
Выпущено большое обновление GnuPG – версия 2.1.0 "modern". Начиная с этого момента будут существовать три поддерживаемые ветки GnuPG
- "modern" 2.1 – последняя версия с большим количеством новых возможностей.
- "stable" 2.0 – текущая стабильная версия.
- "classic" 1.4 – старая версия, не разделённая на компоненты, ныне рекомендуемая для встраиваемых систем.
Разработчики предупреждают, что будет невозможно установить одновременно "modern" и "stable" версию. Однако, можно установить "classic" вместе с любой другой.
Новые возможности версии 2.1
- Файл "secring.gpg" больше не используется для хранения закрытых ключей. Теперь поддерживается объединение закрытых ключей.
- Полностью удалена поддержка PGP2 ключей по соображениям безопасности.
- Добавлена поддержка ECC
- Теперь доступны команды для создания и подписи ключей без каких-либо дополнительных запросов.
- Pinentry теперь умеет показывать поля для ввода и подтверждения парольной фразы в одном диалоге.
- Теперь не нужно запускать вручную gpg-agent. Он будет запущен самим GnuPG, если понадобится.
- Исправлены ошибки при импорте ключей с совпадающими длинными идентификаторами.
- Dirmngr теперь часть GnuPG и используется для доступа к серверам ключей.
- Улучшения в использовании пулов серверов ключей.
- Публичные ключи на локальных связках теперь хранятся в новом формате. Это должно ускорить операции с большими связками.
- Сертификаты отзыва теперь создаются по умолчанию.
- Поддержка смарткарт была обновлена, теперь поддерживается больше новых считывателей и токенов.
- Формат вывода ключей был обновлён.
- gpg-agent теперь может использоваться под Windows как замена pagent для putty точно так же, как он используется в роли замены ssh-agent под Unix.
- Улучшения в создании X.509 сертификатов. Теперь поддерживается экспорт в PKCS#8 и PEM для использования в TLS-серверах.
Детальное описание изменений доступно здесь.
Источник: http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000358.html
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 1079 документов: 58 редакций: 59
Господа, не могу протестировать, нет доступа к компьютеру, подскажите а эта версия в batch-mode 8192-битные ключи генерирует или тоже патчить нужно?
Ну вот почему все упрощается?
"Упрощён штатный интерфейс генерации ключей (gpg2 --gen-key), который стал более прост для генерации подходящих ключей начинающими пользователями. Для создания ключей теперь можно ввести только имя и email."
Теперь вообще размер ключа вводить не нужно?
комментариев: 9796 документов: 488 редакций: 5664
Рискну предположить, что --expert-mode никуда не делся.
Его и раньше не нужно было вводить, если согласен с дефолтным значением.
комментариев: 1060 документов: 16 редакций: 32
А ещё есть --full-gen-key, который совпадает со старым.
комментариев: 1079 документов: 58 редакций: 59
комментариев: 1060 документов: 16 редакций: 32
комментариев: 1079 документов: 58 редакций: 59
Эх, вот почему нельзя в --expert-mode добавить.. Попробую на днях собрать и пропатчить, хотя наверняка там полный game over, код то переписан, еще найти бы.
Кому не сложно – прокомментируйте, пожалуйста, в двух словах этот этап генерации ключа:
Принципиальное различие и что целесообразнее выбирать. Заранее благодарен.
комментариев: 9796 документов: 488 редакций: 5664
Если верить Бернштейну, то обе кривые — плохи. Открытое сообщество (но не разработчики GnuPG?) негласно предпочитает кривые от самого Бернштейна. Кривые от НИСТа вроде и Шнайер критиковал, опасаясь, что там в очередной раз могут выявиться манипуляции с константами, возникшие под давлением АНБ. В том же Tor решили, что если не НИСТ, то только кривые Бернштейна. Хотя сами Brainpool-кривые специально задумывались как выбранные с обоснованно неподтасованными псевдослучайнми числами даже в ущерб оптимизации производительности.
Что касается параметра размера ключа в самой кривой, то можно смело выбирать максимальный — в отличие от RSA это никак существенно не отразится на скорости при (рас)шифровании индивидуальной почты.
комментариев: 1079 документов: 58 редакций: 59
комментариев: 11558 документов: 1036 редакций: 4118
А не опечатка ли это в коде?
The sequence may seem suggestive of a typographic error. Nevertheless, the last value is 521 and not 512 bits.
Why do the elliptic curves recommended by NIST use 521 bits rather than 512?
комментариев: 9796 документов: 488 редакций: 5664
Curve P-521:
The modulus for this curve is p = 2521 – 1. Every integer A less than p2 can be written A = A1 • 2521 + A0
The expression for B is
B := A0 + A1 mod p
© FIPS PUB 186-2
FEDERAL INFORMATION
PROCESSING STANDARDS PUBLICATION
2000 January 27
U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology
Или более общая и свежая версия: FIPS 168-4.
В таблице Binary Field на самом деле — простые числа, а Prime Field, символизирующие стойкость, подбираются, чтобы по ним подобрать ближайшее Binary Field. Чем больше Prime Field, тем сложнее подобрать к нему соотв. Binary Field, так что приходиться использовать 521.
P.S. По поводу этих стандартов НИСТа напрашивается местное крылатое:
© Работу, набранную в ворде, хочется отправлять в мусорное ведро, не читая.
комментариев: 9796 документов: 488 редакций: 5664
Разметка поехала… Или мне кажется?