Добрый день, хабрахабр!

В процессе написания одной из своих программ мне понадобилось разобраться с библиотекой шифрование и де-шифрования текста. Я разобрался и теперь хочу поделиться накопленным опытом и знаниями с сообществом.

В данной статье речь пойдет о библиотеке libgcrypt.

Знаменитый криптограф Ади Шамир (буква “S” в аббревиатуре RSA) с коллегами вчера опубликовал научную работу под названием «Извлечение ключа RSA путём акустического криптоанализа с низкой частотой дискретизации» (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis). За сложным названием скрывается исключительно доступный метод извлечения ключей RSA (в реализации GnuPG) с помощью обычного мобильного телефона или микрофона. Достаточно лишь положить телефон в 30 см от компьютера жертвы. Если использовать качественные микрофоны, то извлекать ключи можно с расстояния до 4 метров.

На самом деле патчим gnupg и libgcrypt…

Когда-то давным давно, чтобы использовать 8192 и 16384 RSA ключи я правил размер в keygen.c и размер SECMEM буффера по соседству. Дела давно минувших дней, теперь SECMEM вынесена в config.h и именуется SECMEM_BUFFER_SIZE.

В итоге после скачивания верии 2.0.29 под свежий debian 8.3, за место убитой 12й убунты апдейтом на 14ую, я быстренько подкрутил размер ключика и размер буфера и радостно сгенерировал на 5200U 16кбит ключ за 18 (или 19) минут, что раньше занимало 45-50 минут на P6200.

Но вот 32кбит дали мне пачку ошибок. Свободное время есть — разбираемся.

Команда GnuPG Project опубликовала сообщение о том, что в популярной библиотеке Libgcrypt содержится критическая уязвимость. Ошибка была обнаружена экспертами Технологического института немецкого города Карлсруэ Феликсом Дёрре (Felix Dörre) и Владимиром Клебановым.

Уязвимость содержится в генераторе случайных чисел Libgcrypt — она позволяет атакующему, который получил 4640 битов из генератора легко предсказать следующие 160 бит его вывода. Это открывает возможность для взлома ключей шифрования. Ошибка присутствует в Libgcrypt и GnuPG версий, выпущенных до 17 августа 2016 года, для всех платформ. Как указано в сообщении GnuPG Project, этот баг существует с 1998 года.

С появлением библиотеки GCrypt-1.7.0 с поддержкой российской криптографии (ГОСТ 28147-89, ГОСТ Р 34.11-94/2012 и ГОСТ Р 34.10-2001/2012), стало возможным говорить о поддержке российского PKI в таких проектах как Kleopatra и KMail.

KMail – это почтовый клиент, который для обеспечения безопасности переписки позволяет подписывать и шифровать сообщения по протоколу S/MIME. И то и другое базируется на архитектуре PKI, сертификатах X509 и протоколах CMS/PKCS#7:

Приближается вторая половина 2018 года и скоро должен наступить «2000-й год» в ИОК на базе российской криптографии. Это связано с тем, что

использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!

Уже сегодня не имеет смысла получать сертификаты с подписью по ГОСТ Р 34.10-2001.

Мы продолжаем разговор об альтернативе openssl и речь пойдет о библиотеке libksba, которая входит в состав GnuPG. Библиотека libksba предоставляет высокоуровневый интерфейс для работы с такими объектами инфраструктуры открытых ключей как сертификаты, запросы на сертификаты, электронная подпись (CMS/PKCS#7). Однако, в отличии от библиотеки GCrypt, в которой реализована поддержка российских криптографических алгоритмов, то в libksba отсутствует реализация рекомендаций ТК-26 по использованию алгоритмов ГОСТ Р 34.10-2001/2012, ГОСТ Р 34.11-94/2012 в таких объектах ИОК как сертификаты, запросы на сертификаты, объекты PKCS#7/CMS (подписанные и/или шифрованные документы и т.п).

В свое время реализация отечественных криптографических алгоритмов в библиотеке libgcrypt очень меня вдохновила. Стало возможным задействовать эти алгоритмы и в Kleopatra и в Kmail и в GnuPg в целом, рассматривать библиотеку libgcrypt как алтернативу openssl с ГОСТ-ым engine. И все было замечательно до прошлой пятницы.