По умолчанию в Fedora и CentOS пакет OpenSSL собран без поддержки криптографии по эллиптическим кривым (ECC, Elliptic Curve Crytography), так как реализация
потенциально [[https://lists.fedoraproject.org/pipermail/legal/2011-June/00... нарушает]] ряд [[http://en.wikipedia.org/wiki/ECC_patents патентов]]. В Debian и Ubuntu пакет openssl собран с поддержкой ECC.На конференции Black Hat USA 2013 группа экспертов по криптографии представила результаты исследования, в результате которого был сделан [[https://threatpost.com/crypto-gains-ramp-up-calls-to-get-ahe... вывод]], что время алгоритма RSA сочтено и пока не поздно вендорам следует перейти на использовании криптографии по эллиптическим кривым. С учётом развития методов ускорения векторных вычислений, уже через пять лет RSA нельзя будет считать безопасным.
++ Пересборка OpenSSL и strongSwan (IPSec) в Fedora.
Удаляем пакет openssl-devel и устанавливаем пакеты, необходимые для сборки:rpm -e openssl-devel
yum install rpm-build krb5-devel zlib-devel gcc \
gmp-devel libcurl-devel openldap-devel \
NetworkManager-devel NetworkManager-glib-devel sqlite-develПодготавливаем сборочное окружение rpmbuild:
[ ! -e ~/.rpmmacros ] && \
echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros
[ ! -d rpmbuild ] && mkdir rpmbuild
cd ~/rpmbuild
mkdir -p BUILD BUILDROOT RPMS/i386 RPMS/x86_64 SOURCES SPECS SRPMS
Загружаем src-пакет, заменяем изменённые исходные тексты на оригинальный openssl и применяем патч для включения сборки с ECC:
cd ~/rpmbuild/SRPMS
wget http://dl.fedoraproject.org/pub/fedora/linux/releases/19/Eve...
rpm -i openssl-1.0.1e-4.fc19.src.rpm
cd ../SOURCES
wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
cd ../SPECS
wget http://zxvdr.fedorapeople.org/openssl.spec.ec_patch
patch -p0 < openssl.spec.ec_patch
sed -i -e 's/-usa.tar.xz/.tar.gz/' openssl.spec
rpmbuild -bb openssl.specУстанавливаем собранный OpenSSL:
cd ~/rpmbuild/RPMS/$(uname -i)
rpm -Uvh --force \
openssl-1.0.1e*rpm \
openssl-devel-1.0.1e*rpm \
openssl-libs-1.0.1e*rpmПроверяем поддержку ECC:
openssl ec -help
Пересобриваем strongSwan, при наличии поддержки ECC в OpenSSL при пересборке strongSwan автоматически определит наличие ECC:
wget http://dl.fedoraproject.org/pub/fedora/linux/releases/19/Eve...
rpm -i strongswan-5.0.2-2.fc19.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bb strongswan.specУстанавливаем strongSwan:
cd ~/rpmbuild/RPMS/$(uname -i)
rpm -Uvh --force \
strongswan-5*rpm \
strongswan-tnc-imcvs*rpmПроверяем strongSwan, пытаясь создать ECDSA-ключ:
cd /tmp
strongswan pki -g --type ecdsa --size 384 > myKey.der
strongswan pki -a --type ecdsa-priv --in myKey.derprivate key with:
pubkey: ECDSA 384 bits
++ Инструкция для CentOS 6.4
Формируем сборочное окружение
yum -y update
yum -y groupinstall 'Development tools'Подключаем репозиторий EPEL
yum -y localinstall --nogpgcheck http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6...Устанавливаем и настраиваем сборочный инструментарий mock из EPEL:
yum -y install fedora-packager
userdel -rf abcd
useradd -G mock abcd
su abcdЗагружаем src-пакет и оригинал openssl
cd ~
curl -O http://vault.centos.org/6.4/os/Source/SPackages/openssl-1.0....
/usr/bin/mock ~/openssl-1.0.0-27.el6.src.rpm
rm -rf /home/abcd/build
mv /var/lib/mock/epel-6-x86_64/root/builddir/build/ /home/abcd
cd /home/abcd/build/SOURCES
curl -O http://www.openssl.org/source/openssl-1.0.0.tar.gzЗагружаем патч, устраняющий вывод ошибки при выполнении тестов
curl -o patch300.patch http://cvs.openssl.org/patchset?cn=19998
Правим spec-файл, включаем режим enable-ec, отключаем скрипт hobble и добавляем патч:
cd ../SPECS
sed -i -e "s/no-ec/enable-ec/; s/no-ecdh/enable-ecdh/; s/no-ecdsa/enable-ecdsa/" openssl.spec
sed -i -e "s/^Source1: hobble-openssl/#&/; s/^%.SOURCE1. /#&/" openssl.spec
sed -i -e "s/^Release.*dist\}/&.EC.1/" openssl.spec
sed -i -e "s/-usa.tar.bz2/.tar.gz/" openssl.spec
sed -i -e "s/^Patch78.*/&\nPatch300: patch300.patch\n/" openssl.spec
sed -i -e "s/^%patch78.*/&\n%patch300 -p1 \n/" openssl.specПересобираем пакет:
/usr/bin/mock --buildsrpm --spec ~/build/SPECS/openssl.spec --sources ~/build/SOURCES
cp /var/lib/mock/epel-6-x86_64/root/builddir/build/SRPMS/openssl-1.0.0-27.el6.EC.1.src.rpm /home/abcd
cd ~
/usr/bin/mock --rebuild openssl-1.0.0-27.el6.EC.1.src.rpm
URL: http://danielpocock.com/ussing-ecc-ecdsa-in-openssl-and-stro... http://unix.stackexchange.com/questions/81081/openssl-packag...
Обсуждается: http://www.opennet.ru/tips/info/2797.shtml
IPSec рекомендует использовать кривые размером 163 и 283 бита!
А именно кривые sect163k1, sect163r1, sect283k1 и sect283r1.
Если вы конечно не ССЗБ и IPSec будет работать только с таким же
компом, а не с андройдами, яблодевайсами, цисками,...А так, да, можно забубенить кривую 571 степени x^571 + x^10 + x^5 + x^2 + 1; =-o
Одобренные спецслужбами кривые всегда рекомендуются :)
как жеж в gentoo все проще:
USE="openssl" emerge openssl strongswan
и сразу с поддержкой ECC и то и другое ^^
Как же в SuSE всё легко - ужо всё есть!
Нарушают патенты? :)
В Германии нет софтпатентов. Как и почти в о всем мире.
Поэтому у них в OpenSUSE такое лютое ШГ по-дефолту, потому CCF в freetype2 не включен из-за патентов?
> Как же в SuSE всё легко - ужо всё есть!Дык как и в дебиане и убунте. При том что если уж фичу воткнули даже дебианщики, долбанутые на таких вопросах по полной программе - похоже что федора перестраховывается.
У дебианчиков взять нечего, по этому они никому не нужны, а redhat постоянно троллят патентами.
В GnuPG когда появится ecc? В девелоперской ветке вроде есть, но уже года полтора в основную не переносят
что за манера писать "статейки" в императивном стиле? деградантство какое-то. явно перечислить список патчей для двух дистрибутивов и дать ссылку на доки по rpmbuild,не? обязательно куча бреда неактуального, в котором полезность статьи растворяется до минимума
Это не статья, а алгоритм сборки.
Это вам. А кто-то другой увидит на живом примере как оно делается.
Ага, увидит, как произносится заклинание.
В школе и универе лабораторные работы прогуливать не надо было! Тогда бы правильная форма подачи материала в подкорке отложилась.
Во-первых, хуже подачу, чем универовские лабы - это еще придумать надо. Во-вторых - есть разница между "дать ссылку на доку" и "показать на примере как применяется инструмент". Тем более, что процесс - прозрачнее некуда. А посмотреть, что за команду использовали явно проще, чем угадать, что именно она здесь нужна. Вон, в половине руководств rpm пихают вместо yum localinstall
Хорошо, за localinstall и mock я прощаю автора. Наверно на меня нашло то, что я прошел по ссылке к статье, там глубже по ссылкам встретился какой-то бред.А на счет лаб: я имею в виду выполнение лабы студентом, и оформление результата, и описание проведения эксперимента. Этому обучают. Что бы было все по полочкам. И понятно другим, воспроизводимо, декларативно. Потому что, это нужно для публикования результатов в рамках международного научного сообщества. Эх, ладно, это уже лирика... Надеюсь, останутся для будущих поколений хотя бы те крохи правильного преподавания, что встречались у меня.
При всем моем уважении к науке и научному сообществу (не шучу ни разу) к науке имеет отношение только очень малая часть выпускников ВУЗов.
> в результате которого был сделан выводБольше напоминающий маркетинговый булшит, если его почитать. Мол, чувак достиг рекордов во взятии экспонент. А насколько сие зацепит длинные RSA ключи - никакого анализа, собственно, нет :). Другое дело что работа с длинными ключами RSA отличается тормознутостью...
http://www.opennet.ru/opennews/art.shtml?num=37846
openssl ec -helpunknown option --help
ec [options] <infile >outfile
...
Не очень уверен насколько это относится к теме, но как минимум NIST больше не рекомендует использовать свой DUAL_EC_DRBG:
http://www.propublica.org/documents/item/785571-itlbul2013-0...
http://www.propublica.org/documents/item/786216-cryptanalysi...
http://rump2007.cr.yp.to/15-shumow.pdf
> Не очень уверен насколько это относится к теме, но как минимум NIST
> больше не рекомендует использовать свой DUAL_EC_DRBG:
> http://www.propublica.org/documents/item/785571-itlbul2013-0...
> http://www.propublica.org/documents/item/786216-cryptanalysi...
> http://rump2007.cr.yp.to/15-shumow.pdfСпасибо, очень познавательно.
Это только алгоритм ГПСЧ. К тому же, довольно тормозной и openssl все равно обычно использует /dev/u?random. Его компрометация на ECDH (схема обмена ключами) и EHDSA (алгоритм подписи) не влияет.
НУ, замечательно!
Класс
Раскрыта деятельность АНБ по внедрению бэкдоров для расшифровки защищённого трафика в Интернет http://www.opennet.ru/opennews/art.shtml?num=37846Шнайер не рекомендует применять стандарты шифрования по эллиптическим кривым, так как АНБ активно участвовало в их разработке.
Вот только интересно - почему же тогда именно американский редхат и не реализует фичу? АНБ что, не может тихой сапой мешающие патенты придушить? :)
Так у них же все строго в США, АНБ разработало бэкдор и запатентовало, потому что как иначе. Теперь предлагают приобрести лицензию, чтобы его можно было использовать. Но пока не все соглашаются.
АНБ занимается не только шпионажем но и собственно защитой национальной безопасности.
Если там есть закладка, то при её раскрытии пострадает больше всего тот у кого она чаще используется - США.
Кроме того: ГОСТ Р 34.10-2012 и ГОСТ Р 34.10-2001 основаны на эллиптических кривых.
http://ru.wikipedia.org/wiki/%D0%93%D0%9...
Есть ещё немецкий вариант и другие варианты параметров для криптографии на эллиптических кривых.
Можете сами сгенерировать себе параметры и распространять их вместе с подписанными данными, наравне с открытым ключём.