LINUX.ORG.RU

Выпуск GnuPG 2.1.0 c поддержкой шифрования по эллиптическим кривым

 


2

4

Спустя восемь лет с момента выпуска GnuPG 2.0 представлен релиз новой значительной ветки инструментария GnuPG 2.1.0 (GNU Privacy Guard), совместимого со стандартами OpenPGP (RFC-4880) и S/MIME, и предоставляющего утилиты для шифрования данных, работы с электронными подписями, управления ключами и доступа к публичным хранилищам ключей.

GnuPG 2.1.0 позиционируется как первый выпуск новой кодовой базы, включающей самые свежие разработки. GnuPG 2.0 рассматривается как стабильная ветка, оптимальная для повсеместного использования. GnuPG 1.4 отнесен в разряд классических версий, потребляющей минимальные ресурсы и подходящей для встраиваемых систем. Ветка 2.1 не может быть установлена одновременно с 2.0. Ветка 1.4 может применяться одновременно с выпусками 2.1 или 2.0.

Особенности GnuPG 2.1:

  • Поддержка шифрования по эллиптическим кривым (ECC, Elliptic Curve Cryptography). Поддерживаются NIST P-256/P-384/P-521 и Brainpool P-256/P-384/P-512. По умолчанию применяется алгоритм Curve 25519 и схема цифровой подписи с открытым ключом Ed25519, разработанная Дэниэлом Бернштейном.
  • Прекращение поддержки устаревших ключей PGP2, не отвечающих современным требованиям к безопасности из-за использования хэшей MD5.
  • Прекращено использование файла «secring.gpg» для хранения закрытых ключей. Доступ к закрытым ключам теперь возможен только через gpg-agent, который хранит ключи в директории private-keys-v1.d. Напрямую gpg к закрытым ключам отныне обращаться не может. Добавлена поддержка слияния закрытых ключей.
  • Задействован новый формат для локального хранения публичных ключей, обеспечивающий большой прирост производительности для больших таблиц ключей (keyring).
  • Упрощён штатный интерфейс генерации ключей (gpg2 --gen-key), который стал более прост для генерации подходящих ключей начинающими пользователями. Для создания ключей теперь можно ввести только имя и email.
  • Добавлены команды для создания и подписания ключей из командной строки без дополнительных запросов ввода параметров (например, «gpg2 --batch --quick-gen-key 'Vasyliy Pupkin vasia@example.org' или „gpg2 --quick-sign-key '15CA 723E 2030 A1A8 2505 F3B7 CC10 B501 BD19 AC1C'“).
  • В Pinentry обеспечена возможность показа полей ввода нового пароля и его подтверждения в одном диалоге.
  • Пользователь избавлен от необходимости ручного запуска gpg-agent, который теперь вызывается автоматически из других частей GnuPG.
  • Обновлена поддержка смарткарт, добавлена поддержка новых устройств чтения и типов токенов.
  • Улучшена обработка пулов серверов ключей (keyserver), используемых для балансировки нагрузки. Кроме распределения запросов на основе DNS в новой версии представлен процесс dirmngr, распределяющий запросы с учётом возможного выхода из строя отдельных серверов (если сервер не отвечает, выбирается другой сервер).
  • По умолчанию теперь для всех пар ключей создаётся отзывающий сертификат (revocation certificate).
  • Обеспечена возможность использования gpg-agent на платформе Windows в качестве замены Pageant для Putty.
  • Улучшен процесс создания сертификатов X.509. Обеспечена возможность экспорта сертификатов X.509 в форматы PKCS#8 и PEM для использования на серверах TLS.

>>> Источник

anonymous

Проверено: Shaman007 ()

Нужно!

Поддержка шифрования по эллиптическим кривым

А разве DSA работает не с эллиптическими кривыми?

Klymedy ★★★★★ ()

Упрощён штатный интерфейс генерации ключей

Куда упрощать-то?

Deleted ()

Поддержка шифрования по эллиптическим кривым

АНБ бэкдоры кококо
Кто-то должен был это написать.

MrClon ★★★★★ ()
Последнее исправление: MrClon (всего исправлений: 1)

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

У меня не бывает ни дня чтобы я не запустил gpg. Чаще всего шифрую бэкапы всякие им и то что храню в облаке.

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

soko1 ★★★★★ ()
Ответ на: комментарий от MrClon

Именно поэтому

По умолчанию применяется алгоритм Curve 25519 и схема цифровой подписи с открытым ключом Ed25519, разработанная Дэниэлом Бернштейном;

А не NIST'овые :)

mva ()
Ответ на: комментарий от soko1

За 100500 лет использования в Psi/Psi+ никогда не было «работает через раз». ЧЯДНТ?

mva ()

Поддержка шифрования по эллиптическим кривым

Потом очередной математик внимательно поработает с теорией - и снова дыра в безопасности размером со штат Канзас.

anonymous ()
Ответ на: комментарий от mva

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

soko1 ★★★★★ ()
Ответ на: комментарий от soko1

Чаще всего шифрую бэкапы всякие им и то что храню в облаке.

В теме ничего не смыслю, но интересно):

Правильно я понимаю, что прежде чем воспользоваться чем-то из облака, надо это что-то скопировать себе на диск и расшифровать?

Не логичнее ли использовать на бекапах симметричное шифрование через тот же aes, встроенный в 7z? Ассиметричное же вроде придумано для случаев конда надо обмениваться информацией с кем-то

makoven ★★★★★ ()
Ответ на: комментарий от makoven

Не логичнее ли использовать на бекапах симметричное шифрование через тот же aes, встроенный в 7z?

Еще логичнее использовать encfs, которая шифрует данные «на лету» прозрачно для пользователя.

anonymous ()
Ответ на: комментарий от makoven

Так я симметричное и использую, оно ж умеет :) Ключик -c к gpg.

Так, всё верно, для того чтобы получить файло его необходимо слить и расшифровать (ключ -d).

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

soko1 ★★★★★ ()
Последнее исправление: soko1 (всего исправлений: 1)

Эллиптические кривые заброковали?

«Эллиптические кривые» вроде как забраковали после Сноудена. Развет нет?

Windows ★★ ()

Curve 25519

Ням-ням, вот это годнота!

Macil ★★★★★ ()
Ответ на: комментарий от anonymous

Потом очередной математик внимательно поработает с теорией - и снова дыра в безопасности размером со штат Канзас.

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

Так что если какой-то дикий математик вздумает «внимательно поработать с теорией», то скорее это у него в голове появится дыра размером со штат Канзас. И очень быстро, ЧСХ.

Macil ★★★★★ ()
Ответ на: комментарий от soko1

асимметричное всё же безопаснее

Очень странное утверждение, как и его обоснование

anonymous ()
Ответ на: комментарий от anonymous

Достаточно взглянуть на его аватарку, он же говнарь, а все говнари туповатые

anonymous ()
Ответ на: Эллиптические кривые заброковали? от Windows

Развет нет?

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

Закладки делают в реализациях, так удобнее.

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Klymedy

Не удивлюсь, если до этого анб вбахало кучу бабок и создало CPU массив, заточенный на перебор точек этих кривых. А опенсорсникам проплатили за впихивание (уже подготовленного к взлому на этих cpu) алгоритма хомячкам.

menangen ★★★★★ ()
Ответ на: Эллиптические кривые заброковали? от Windows

«Эллиптические кривые» вроде как забраковали после Сноудена. Развет >нет?

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

maximnik0 ★★ ()
Ответ на: комментарий от mtk

Вот покушать принес про PGP

Это плохая, негодна еда. Хорошая годная еда о вреде ЭЦП *вообще* лежит на сайте zphone (детища дедушки Циммермана, на минуточку), в разделе «мотивация почему zphone не использует PKI».

Примерно такая же мотивация есть и у Яна Гольдберга, автора OTR.

К сожалению, Циммерману в своё время не хватило крепости яиц слить PGP к собачьим чертям. Единственное, что его может извинить, PGP используется в основном гиками. А их тупо *не жалко*.

Macil ★★★★★ ()
Ответ на: комментарий от soko1

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

n-битный RSA ключ не эквивалентен по стойкости n-битному AES ключу.
Ключ для AES это просто любое число заданной длинны, а ключ для RSA — простое число заданной длинны. Простых чисел меньше чем просто чисел, следовательно при равной длинне число возможных ключей RSA сильно меньше числа возможных ключей AES.
Буквально пару дней назад на глаза попадалась таблица соответствия криптостойкости длин ключей для разных алгоритмов, но найти сейчас не могу.
Впрочем сопоставление там достаточно условное и привязанное к текущим возможностям железа.

MrClon ★★★★★ ()
Ответ на: Эллиптические кривые заброковали? от Windows

Re: Эллиптические кривые заброковали?

В алгоритмах на элептических кривых, кроме самого алгоритма и ключей нужны некоторые константы (собственно кривые). Выбор кривой зависит от конкретного стандарта шифрования (можно считать кривую частью алгоритма, если угодно).
Предполагается что кривые созданные при участии АНБ (одобренные АНБ) намеренно «ослаблены». Соответственно эти кривые, в определённых кругах, считаются скомпрометированными.
Кривые созданные до того как АНБ включилось в процесс считаются кошерными (по крайней мере с меньшей степенью вероятности скомпрометированными).

MrClon ★★★★★ ()

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

следует ли это понимать так, что 2.0 - тормозное говно?

MyTrooName ★★★★★ ()
Ответ на: комментарий от soko1

Ну и да, асимметричное всё же безопаснее, т.к. используется ключ большой длинны + пароль к этому ключу.

Не безопаснее. У асимметричного шифрования просто своя область применения - цифровая подпись, обмен ключами. Часто используются совместно с симметричными, в том же SSL. Для шифрования больших объемов данных лучше использовать симметричные алгоритмы - работают гораздо быстрее.

Vovka-Korovka ★★★★★ ()
Ответ на: комментарий от MrClon

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

http://www.keylength.com/en/4/

Vovka-Korovka ★★★★★ ()

Помогите, друзья!

1) Можно ли этой программой шифровать файлы?

2) Что есть в официальных «репах» Ubuntu для шифрования файлов?

---> Спасибо всем, кто откликнется!

anonymous ()
Ответ на: Помогите, друзья! от anonymous

Re: Помогите, друзья!

1) Можно, разрешаю.
2) GnuPG. А ещё в убунте, в контекстном меню файла, есть пункт «зашифровать».

MrClon ★★★★★ ()

Ребята, я правильно понимаю, что это офигительно мощная технология, и если я этой фиговиной зашифрую свои файлы, то фиг кто меня взломает, так? Никакие АНБшники и прочие отбросы цивилизации не страшны этой проге?

anonymous ()
Ответ на: комментарий от anonymous

Проге — нет, а вот твоей заднице — вполне. :)

anonymous ()

ГОСТ_Р_34.10-2012 там нет, как я понимаю...

drfaust ★★★★★ ()
Последнее исправление: drfaust (всего исправлений: 1)
Ответ на: комментарий от BruteForce

Неплохо. Но у этой тулзы есть как минимум один минус - требуется наличие прав рута для монтирования, что не всегда удобно и вообще возможно.

Кстати, эта штука намного ли лучше encfs? Принцип я смотрю схожий, функции те же. И производительность тоже интересует, ибо encfs ещё тот тормоз + fuse требует. Короче поделись если конечно в курсе, плз.

soko1 ★★★★★ ()
Ответ на: комментарий от soko1

man gnupg

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

Поправка, private/secret (sub)keys не имеют срока и никогда не истекают, а следовательно расшифроврать данные можно всегда, когда есть private/secret key :-) (ну и если свой пароль к нему помните ещё, если установили)

Что истекает, так этот только (pub)ublic master signing key и public (sub)ordinate key:

pub  4096R/26B6AAE1  created: 2014-06-15  expires: 2015-06-15  usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/0CF8CB7A  created: 2014-06-15  expires: 2015-06-15  usage: E   
[ultimate] (1). Chloe (Jester) <chloe@cyb.org>

private/secret key:

gpg> toggle

sec  4096R/26B6AAE1  created: 2014-06-15  expires: 2015-06-15
ssb  4096R/0CF8CB7A  created: 2014-06-15  expires: never     
(1)  Chloe (Jester) <chloe@cyb.org>

видете «ssb expires: never», ssb => 'Secret SuBkey'

sub ключи используются для шифровки (encryption)

pub ключи используются для подписки (signing) и сертификации др. подписей

PUBKEY_USAGE_SIG      S       key is good for signing
PUBKEY_USAGE_CERT     C       key is good for certifying other signatures
PUBKEY_USAGE_ENC      E       key is good for encryption
PUBKEY_USAGE_AUTH     A       key is good for authentication

Более того, даже если срок ключа истёк, вы всегда можете сбросить срок истечения и продлить истёкшие public ключи.

arno ()
Ответ на: комментарий от Vovka-Korovka

gpg RSA AES

Для шифрования больших объемов данных лучше использовать симметричные алгоритмы - работают гораздо быстрее.

GPG, PGP, SSH и большинство public key систем уже относительно давно используют симметрическое шифрование внутренне.

Асимметрическое шифрование (напр. криптосистема RSA) используется только для того, чтобы зашифровать сгенерированный симметрический ключ, которым информация будет зашифрована (используя напр. стандарт AES основанный на алгоритме Rijndael). Секретный ключ используется для дешифровки симметрического ключа, который потом используется для дешифровки.

Сами пользователи не видят симметрический ключ.

Пользователи видят только: public ключи, plaintext, ciphertext, secret ключи.

Симметрические ключи - внутренняя часть криптосистем и никогда не «открываются» для пользователей.

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

По этой причине, в случае если вы поменяете пароль своего GPG/PGP ключа, вы всё ещё можете расшифровать файлы которые были зашифрованы вашим public ключом в прошлом.

arno ()
Ответ на: man gnupg от arno

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

А вообще программа очень функциональная и сложная, хорошо если я 5% функционалом пользуюсь, особенно второй ветки касается.

И да, спасибо за подробное описание.

soko1 ★★★★★ ()
Ответ на: gpg RSA AES от arno

По этой причине, в случае если вы поменяете пароль своего GPG/PGP ключа, вы всё ещё можете расшифровать файлы которые были зашифрованы вашим public ключом в прошлом.

Интересная мысль, а то у меня реально вагон паролей к каждому архиву отдельно - немного по-идиотски. А по скорости как оно? Ес-но медленнее?

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

soko1 ★★★★★ ()
Последнее исправление: soko1 (всего исправлений: 1)
Ответ на: gpg RSA AES от arno

Кстати, может вам известен какой-либо инструмент вроде encfs/encryptfs на базе gnupg? Грубо говоря хочется выполнять команду вроде `encfs /dir1 /dir2` и получать в каталоге dir1 зашифрованную копию того, что было скопировано в каталог dir2 (шифрование «на лету») только без дурацких fuse и прав рута. Имхо, очень не хватает такого.

soko1 ★★★★★ ()
Ответ на: комментарий от soko1

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

Менять ключи или пароли это всё зависит от самого тебя. Некоторые меняют свои пароли каждые 3 месяца, а это просто пароли. Некоторые вообще не меняют свой пароль в течении 5 а то и более лет... Если нехочешь хранить гору ключей, тогда перешифруй все старые бэкапы со старого на новый ключ. А старый ключ потри хорошенько :)

А по скорости как оно? Ес-но медленнее?

Не замерял. Как я упомянул выше, GPG это hybrid-solution, что означает в случае применения асиметрического шифрования будет (невидимо для пользователя) сгенерирован random-симметрический ключ которым сама информация и будет зашифрована (см. --cipher-algo в man gpg, по умолчанию это CAST5, а не AES). После того как информация будет зашифрована этим random-симметр. ключом, этот самый ключ будет асимметрически зашифрован (вашим public ключом), и будет частью зашифрованного файла.

если бекапы находятся и шифруются на удалённом сервере

тогда дорога только для асимметрического шифрования, естественно приватный ключ должен быть в самом секретном месте, желательно на USB ключе и подключен к системе которая никогда не выходит в интернет (если уже совсем параноиком быть, хотя даже и это не спасёт http://www.tau.ac.il/~tromer/acoustic/).

Ну либо тогда создавать для бекапов свой приватный ключ отдельно

Не нужно. Разве что у вас гетерогенная система где всё на разных уровнях безопасности (напр. секретные ключи на разных уровнях безопасности)

какой-либо инструмент вроде encfs/encryptfs на базе gnupg?

encfs никогда не использовал и не буду, см. http://en.wikipedia.org/wiki/EncFS#Disadvantages

на текущий момент не вкурсе о такой программе, хотя подумав немого, /dir2 так или иначе будет mount-point какого-нибудь device'а через device-mapper... тогда почему бы не использовать cryptsetup/LUKS ?

рабочий пример,

1. добавляем пользователя в группу «disk» чтобы был доступ к loop-девайсам

root ~ # ls -la /dev/loop0
brw-rw---- 1 root disk  7,   0 Nov 12 10:13 /dev/loop0
root ~ # usermod -a -G disk arno

2. создаём контейнер размером 100Mb

user ~ $ dd if=/dev/zero of=container bs=1 count=0 seek=$((1024*1024*100))

3. ищем свободный loop-device и подключаем к нему наш контейнер

user ~ $ losetup -f
/dev/loop0
user ~ $ losetup /dev/loop0 container 
user ~ $ losetup -a
/dev/loop0: [fc01]:3452634 (/home/arno/container)

4. создаём LUKS разметку, подключаем LUKS-device, создаём EXT4 FS (под рутом, но только один раз)

root ~ # cryptsetup luksFormat /dev/loop0
root ~ # cryptsetup luksOpen /dev/loop0 decont
root ~ # mkfs.ext4 -L mycontainer /dev/mapper/decont
root ~ # mount /dev/mapper/decont /mnt/1/
root ~ # chown arno:arno /mnt/1/
root ~ # umount /mnt/1/
root ~ # cryptsetup luksClose decont

Теперь можно использовать свой зашифрованный контейнер без root, просто «losetup /dev/loop0 container» и увидете новый диск в File Browser'е, кликните на него, введёте пароль вот и /dir2 вам в user-space.

Если это удалённый сервер без root-доступа, тогда просто скопируй этот контейнер на этот сервер и используй. (Правда доступ к loop-девайсам ещё понадобится...)

user ~ $ losetup /dev/loop0 container
user ~ $ udisksctl unlock -b /dev/loop0
Passphrase: 
Unlocked /dev/loop0 as /dev/dm-2.
user ~ $ udisksctl mount -b /dev/dm-2 
Mounted /dev/dm-2 at /media/arno/d1887626-d235-4d01-9ed4-c8976a2a6dcc.

user ~ $ udisksctl unmount -b /dev/dm-2 
Unmounted /dev/dm-2.
user ~ $ udisksctl lock -b /dev/loop0
Locked /dev/loop0.

user ~ $ losetup -d /dev/loop0

на базе gnupg?

есть скрипт здесь, позволяющий использовать crypsetup на базе gpg http://www.saout.de/pipermail/dm-crypt/2011-March/001587.html

если поискать «cryptsetup openpgp» много чего можно найти

arno ()
Ответ на: комментарий от arno

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

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

В моей ситуации это именно такой случай. Когда есть просто файлы какой-то системы с дампами СУБД и прочим барахлом, которая не должна попасть в открытом виде к третьему лицу. То есть достаточно зашифровать имена файлов и содержимое. encfs отстой по ряду причин, luks-контейнеры я уже сказал чем не устраивают, делать архив и криптовать его gpg долго, если объёмы серъёзные. Хочется без архивации , без больших контейнеров и без прав рута. gnupg обладает всем набором необходимых мне функций, осталось лишь скрипт написать для него, который будет выполнять условие. Обидно просто будет если такой скрипт уже давно написан и в разы лучше моего, а я не в курсе просто и зря время потрачу.

/dir2 так или иначе будет mount-point какого-нибудь device'а через device-mapper

Я наверное не так выразился. Монтирование тут не при чём. Подойдёт даже вот такое:

gnupgcp /dir /dir2

Где gnupgcp скрипт, который копирует файло из одного места в другое путём «живого» шифрования утилитой gnupg содержимого и названия файлов.

Не слышали про такой инструмент часом?

soko1 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.