V2008 1 фев 2017 в 10:52

CryptoAPI ядра Linux: разработка и применение российской криптографии

8 мин

15K

Проектирование API * Информационная безопасность * Криптография * Linux * Системное программирование *

Из песочницы

+18

Комментарии 26

OlegAndr 1 фев 2017 в 16:51

Все, теперь мы можем создавать шифрованные ФС

И нести его на спец. исследования в ФСБ(*) :-)
Но очень интересно, спасибо.
*Убедитесь в наличии у вас всех соответствующих лицензий.

V2008 1 фев 2017 в 20:19

Ну нести это имеет смысл только если будет востребовано. В текущей ситуации и ценами на сертификацию — проводить тематические исследования в инициативном порядке по линии ФСБ просто убыточно.

saipr 2 фев 2017 в 20:10

А какое отношение спец исследования имеют к защите раздела/диска? И при чем лицензии?

OlegAndr 3 фев 2017 в 11:59

Ну как же.
Обычно заморачиваться с ГОСТ для шифрования имеет смысл только там, где это обусловлено требованиями законодательства, ибо в остальных случаях надо использовать AES с аппаратным ускорением, которое позволяет вообще не замечать наличия FDE.
А там где требования законодательства, там и требования по сертификации полученного результата. Да даже и без этого, осуществление работ связанных с криптографической защитой — уже лицензируемый вид деятельности. Тут только если Топикстартер захочет нам рассказать как ему удается проскочить между этими струйками.
В редких случаях я слышал «надо чтобы по госту, но сертифицировать не обязательно».

Kolyuchkin 3 фев 2017 в 13:29

Чтобы избежать сертификации нужно шифровать не «по ГОСТ-у», а по алгоритму «на базе алгоритма ГОСТ» и обязательно с «малой длиной ключа» (до недавнего времени это было менее 56 бит). Тогда это «поделие» попадает под определение «не подлежащее сертификации». Делается это достаточно просто — в паспорте (или в документе, заменяющем его) делается упоминание, что константная составляющая ключа имеет следующий вид <константная составляющая ключа, например, в шестнадцатиричном представлении>. В «поделии» эта составляющая записывается в виде константы и при выполнении преобразований объединяется с «малой» частью ключа.

OlegAndr 3 фев 2017 в 14:59

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

xalkin 6 фев 2017 в 11:25

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

Просто ГОСТовые алгоритмы шифрования, из-за отсутствия их аппаратной поддержки, оказываются гораздо медленней AES-а, из-за чего для практических целей они как правило менее предпочтительны. Поэтому очень мало для кого представляет интерес заниматься ими в случае, если нет заказчика, которому это действительно надо. А такой заказчик ровно один — государство — и для себя этот заказчик как правило требует еще и сертификацию решений. Если же не пытаться поставлять свои решения этому заказчику прямым или косвенным образом, то и требований по сертификации нет.

Ограничение на длину ключа в 56 бит было в законодательстве США, для экспорта криптографических решений из Америки. К Российским алгоритмам, программам и разработкам это не имеет абсолютно никакого отношения.

OlegAndr 6 фев 2017 в 11:47

ORLY?

3. Настоящим Положением необходимо руководствоваться при разработке, производстве, реализации и эксплуатации средств криптографической защиты информации конфиденциального характера в следующих случаях:
если информация конфиденциального характера подлежит защите в соответствии с законодательством Российской Федерации;

А это очень многое,
а Постановление Правительства РФ от 16.04.2012 N 313 относит действия автора к " ДЕЯТЕЛЬНОСТИ ПО РАЗРАБОТКЕ, ПРОИЗВОДСТВУ, РАСПРОСТРАНЕНИЮ ШИФРОВАЛЬНЫХ (КРИПТОГРАФИЧЕСКИХ) СРЕДСТВ,"
а, это уже лицензируемый вид деятельности.
Длинна ключа также прописана в Постановлении Правительства РФ от 16.04.2012 N 313…

xalkin 6 фев 2017 в 13:02

Приведенная вами цитата из приказа ФСБ как раз и относится к тому заказчику, о котором я написал выше.

А у Постановления №313 такое количество исключений, что для того, чтобы под него подпадать, необходимо оказывать коммерческие услуги по разработке и использованию СКЗИ, чего автор явно не делает. И размер ключа в этом постановлении указан в том аспекте, что оно к малым ключам вовсе не относится, т.е. просто невозможно получить эту лицензию, предоставляя услуги по шифрованию с использованием коротких ключей.

milabs 8 фев 2017 в 12:32

ГОСТ 28147-89 при правильной реализации на AVX не уступает в скорости аппаратной реализации AES (AES-NI).

xalkin 8 фев 2017 в 14:53

Вы хотите сказать, что производительность аппаратной реализации ГОСТ 28147-89 не хуже чем аппаратная реализация AES? С этим спорить не буду. Только вот аппаратная реализация AES есть чуть ли не у утюгов, а где есть аппаратная реализация ГОСТ 28147-89? В токенах, работающих по USB1/2?

milabs 8 фев 2017 в 14:57

Не, я имел в виду реализацию шифра ГОСТ 28147-89 на x86 с использованием расширения команд SSSE3/AVX.

icoz 1 фев 2017 в 22:33

У меня одного есть сомнения в полезности диска, который шифруется в 30 раз медленнее, судя по вашему тесту?

saipr 2 фев 2017 в 20:08

Глядя для чего вы используете шифрование. К тому же если вам нужна конфиденциальность, то потеря 2-10 секунд…

oYASo 1 фев 2017 в 22:48

Не в Astra Linux ли все это ожидается?

V2008 2 фев 2017 в 07:03

На Astra Linux не проверяли. На данный момент используем Debian 8 и Mageia.

xalkin 2 фев 2017 в 07:21

Вообще-то хеш канонично называется streebog. А кузнечик хоть и не плох, но для него к сожалению нет аналога AES-NI. Но вообще такие модули могут быть весьма полезны.

V2008 2 фев 2017 в 14:22

Все по разному называют:

https://ru.wikipedia.org/wiki/ГОСТ_Р_34.11-2012

↑ Матюхин Д. В., Шишкин В. А., Рудский В. И. Перспективный алгоритм хеширования // Доклад на конференции РусКрипто’2010,2010.
↑ http://eprint.iacr.org/2013/556.pdf
↑ «F. Mendel, N. Pramstaller, C. Rechberger, M. Kontak, J. Szmidt» CRYPTO 2008
↑ Riham AlTawy, Aleksandar Kircanski and Amr M. Youssef. Rebound attacks on Stribog (2013).
↑ Riham AlTawy and Amr M. Youssef. Integral Distinguishers for Reduced-round Stribog (2013).
↑ http://www.streebog.info/ Открытый конкурс по исследованию функции
↑ http://www.streebog.info/news/opredeleny-pobediteli-konkursa-po-issledovaniyu-khesh-funktsii-stribog/ Определены победители конкурса по исследованию хеш-функции «Стрибог»
↑ Jian Guo, Jérémy Jean, Gaëtan Leurent, Thomas Peyrin, Lei Wang. The Usage of Counter Revisited: Second-Preimage Attack on New Russian Standardized Hash Function (2014).
↑ Alex Biryukov, Léo Perrin, Aleksei Udovenko. The Secret Structure of the S-Box of Streebog, Kuznechik and Stribob (2015).
↑ Alex Biryukov, Léo Perrin, Aleksei Udovenko. Reverse Engineering the S-Box of Streebog, Kuznechik and Stribob (2015).
↑ [1]
↑ GitHub — okazymyrov/stribog

xalkin 2 фев 2017 в 14:54

Из приведенного списка во всех официальных названиях алгоритм транслитерируется именно как streebog. С ошибкой его иногда называют сторонние исследователи.