ГОСТ-криптография и GnuPG

Кстати, а черновиком iso-шного приложения или s-box из него кто-нибудь может поделиться?

Раз речь идёт о национальном российском стандарте, почему бы ФСБ не взять и не разобраться детально в его работах, обобщив их на другие наборы S-блоков и опубликовав все результаты? Ну, чтобы, так сказать, дать окончательный ответ на все эти вопросы. В конце концов, при необходимости можно было бы связаться с Куртуа, узнать у него все детали, опущенные в его работе. ФСБ кто-то это запрещает всё? Или «прогибаться» не привыкли? Привыкли буром переть, используя административный ресрус? Тогда им на их место в ISO уже указали, всё заслуженно.


PGP есть PGP, зачем там S/MIME и PKI? Это почти ортогональные приблуды к идее PGP. Ну, и незачем переуслжнять стандарт, к большей безопасности это точно не ведёт.


А есть пруфы того, что он эти S-блоки взял из таких систем? Он об этом заявлял? Никто до сих пор не удосужился у него спросить, откуда он взял S-блоки?


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

[флейм вырезан цензурой]

Кстати, а черновиком iso-шного приложения или s-box из него кто-нибудь может поделиться?

Кстати, должны быть или вот-вот появятся какие-то методические рекомендации ТК26. На данный момент у них на сайте опубликовано лишь разъяснения касающиеся шифрования в рамках схемы PBES2:

При практической реализации парольной защиты с использованием алгоритмов ГОСТ рекомендуется использовать следующие параметры: id-Gost28147-89-CryptoPro-A-ParamSet для шифрования данных в рамках схемы PBES2 с использованием алгоритма ГОСТ 28147-89 [5] и id-GostR3411-94-CryptoProParamSet для контроля целостности в рамках схемы PBMAC1 с использованием алгоритма ГОСТ Р34.11-94 [4].

Сам лично запихнул бы в код пока что эти узлы замены. Из расчета, что для отладки и прогона проверочных примеров они сгодятся лучше других. После того как поделка начнет успешно проходить все юнит-тесты, тогда уже можно будет думать об использовании других s-блоков.
Да и именно с ними ГОСТ реализован в OpenSSL. Собственно переписывая код под GPL можно будет взять все тесты у OpenSSL.

Набросал на коленке сайт.

Пока жду ответа от Вернера про 34.10, посмотрел на libksba (библиотека, отвечающая за x.509/crl/cms в gpg). Мрак и ужас.

Add support for GOST encipherment in GnuPG ∎

Не знал, что такое слово существует, впервые слышу.

lumag, зачем лично вам нужна поддержка ГОСТ в GnuPG/libgcrypt? Вы же вроде неглупый человек, могли бы заняться и более осмысленной деятельностью, чем добавка азиатских алгоритмов в стандарты. Неужели Mentor Graphics собралась реализовывать криптопродукцию на российский рынок?

Существует, просто редко используется.

Осмысленной деятельности мне хватает на работе. А для развлечения я хочу выбирать то, что мне сейчас интересно.

Обычно наоборот, ГОСТ для работы используют. В принудительном, так сказать порядке. А для развлечений что-нибудь другое. Но у всех, конечно, свои интересы. Если только для развлечений и отдыха от осмысленной деятельности, то ничего плохого в этом нет.

Объем и характер работы при добавлении какого-либо алгоритма в libgcrypt практически никак не зависит от самого этого алгоритма.
Практически без разницы будет ли это семейство ГОСТов или что-то ещё. При условии, что уже есть хотя бы один корректный и проверенный вариант реализации данного алгоритма в виде готового кода.
Даже если исходить сугубо с этих соображений, то позиция lumag более чем ясна и понятна.

Конечно, гораздо полезнее тратить свободное время на семью, друзей с родственниками или спорт. Однако бывают ситуации сродни обязательных жопочасов в офисе. Когда работы мало, а хочешь или не хочешь, но приходится «нести вахту» в обмен на регулярную зарплату с премией. И либо человек деградирует убивая время на зависание в интернетах, да социальных сетях. Либо занимается саморазвитием повышая квалификацию — читая литературу или возясь с вещами сродни libgcrypt.

Так это всё понятно и замечательно, в резюме напишет полезные навыки, тот же Linux изначально "Just for fun" создавался.

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

Есть ли у кого-нибудь желание озаботиться дизайном/реализацией для поддержки алгоритмов в OpenPGP

То, что человеку дали возможность созвать единомышленников под это дело именно в плане ГОСТов в т.ч. и через PGPru.com вовсе не исключает, что активные участники PGPru считают такое дело не просто бесполезным, но и идущим в разрез с целями проекта. Хочет человек пиарить свой проект — пусть будет готов, что его цели могут встретить здесь неприятие. Более того вместо содействия, тому же Вернеру может быть отправлено письмо, ну если не с протестом, то с просьбой изолировать все недоверяемые алгоритмы в отдельную библиотеку, лишённую статуса доверяемой и официальной поддержки OpenPGP. По аналогии того, как ГОСТ выкинули из ядра Linux (crypto-API).

И дело не только в российских ГОСТах, некоторые азиатские алгоритмы шифрования, а также подозрительне ГПСЧ, протащенные в стандарты от АНБ США без конкурса, в свободном некоммерческом ПО также не хотелось бы видеть.

unknown,

Я очень спокойно и положительно отношусь к здравой критике.

Цели у меня простые – иметь возможность взаимодействовать с отечественными криптосервисами не только через OpenSSL или софт от CP. Например, если какие-нибудь госуслуги вдруг станут работать только с данными, подписанными на УЕК, я хочу иметь альтернативные реализации софта. Я не знаю, какие винтики покрутятся у создателей какого-нибудь https://ццц.дума.рф, но если туда вкрутят только гост-криптографию, я не хочу чувствовать себя человеком второго сорта, не имеющим туда доступа. Аналогичная история с dnssec. Если я правильно оцениваю происходящее, у нас нет гарантии, что какой-нибудь чиновник не решит использовать, что подписывать записи в зонах надо именно "optional" алгоритмами. В любом случае, до реализации OpenPGP или TLS мне еще пока очень далеко.

Далее. Если 28147-89 действительно вызывает много вопросов про S-boxы (а вместе с ним и 34.11-94), то 34.10-01/-12 прозрачны, дальше некуда. Поправьте меня, пожалуйста, но это тот же Эль-Гамаль, вид сбоку. Либо мы выкидываем и ECDSA, и 34.10-0x, или мы доверяем обоим стандартам. Я не знаю, как относиться к Стрибогу, подождем статей с криптоанализом.

P.S. Я не нашел в гите Linux упоминаний гостовых алгоритмов. Ни в текущем дереве, ни в истории. Все, что подарил мне на эту тему Google, – это статья студентов Бауманки. Ни кода, ни патчей – только pdf-ник.

ГОСТ там было ещё очень давно, но возможно не в официальном ядре, а ещё тогда, когда cryptoAPI выкладывалось на kernel.org отдельным патчем. Может перед тем, когда cryptoAPI включили в стандартное ядро, его оттуда и выкинули.

Алгоритм м.б. прозрачнее дальше некуда и никаких вопросов у криптографов не вызывать. Но, хотелось бы, чтобы существовали только алгоритмы, разрабатываемые в открытую. В этом плане российские и азиатские алгоритмы, претендующие на включение в стандарты, несут плохой пример в плане методики разработки. Да и с ECC в этом плане также плохо, поэтому Torproject отказался от официальных стандартов ECC, тянущихся от Цертикома/АНБ и перешёл на реализацию DJB.

Цели у меня простые – иметь возможность взаимодействовать с отечественными криптосервисами не только через OpenSSL или софт от CP. Например, если какие-нибудь госуслуги вдруг станут работать только с данными, подписанными на УЕК, я хочу иметь альтернативные реализации софта. Я не знаю, какие винтики покрутятся у создателей какого-нибудь https://ццц.дума.рф, но если туда вкрутят только гост-криптографию, я не хочу чувствовать себя человеком второго сорта, не имеющим туда доступа. Аналогичная история с dnssec. Если я правильно оцениваю происходящее, у нас нет гарантии, что какой-нибудь чиновник не решит использовать, что подписывать записи в зонах надо именно "optional" алгоритмами.

Так они и рассчитывают продвигать алгоритмы путём навязывания. Вместо того, чтобы объявить такую практику неизбежным злом, достойным порицания и вынести поддержку нечестно проталкиваемых алгоритмов в отдельные библиотеки, вы включаетесь в игру на стороне проталкивателей против свободного криптосообщества. Предложен же разумный компромисс: придумайте способ того, чтобы по умолчанию это не ставилось, чтобы пользователи Linux-дистрибутива могли поставить поддержку таких алгоритмов только отдельными пакетами, не вшитыми намертво в стандарные утилиты и либы, не тащите это туда.

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

lumag, заделайте в mplayer пораскадровую перемотку, что бы как там, 24 кадра в секунду, вот что бы все 24, и если их 25, то 25, можно было отдельными джы-пегами посмотреть, или фильм в слайдшоу превратить. В проприетарных обработчиках видио это давно уже, надо что бы расскадровка была типа anti-stego.

Вот например, врезали 25 кадр в середину фильма, и фильм весь монотонный плавный, а кадр не замечает чел. глаз, такое бывает. Вот что бы примочка эта вырывала все резкие переходы и в джы-пеге их хранила, вот бы было здорово.
Типа скриншота с фильма, но автоматом, если первый кадр != следующему больше чем на 10%, то оба кадра сохранить.

И эти 10% задаются юзером. Ну типа, 50%. хуяк кадр на 50% отличается от предыдущего, оба кадра, и этот и предыдущий -> имя_фильма_таймстэмп.1.jpg, имя_фильма_таймстэмп.2.jpg (Save).

По похожему принципу действует детектор движения ( motion sensor ). Сохраняет текущую с камера картинку, если картина меняетя, это типа плавающего хэша от изображения, там целая наука, не берусь сейчас точно сказать, если эти хэши отличаются на 10% друг от друга, motion sensor начинает пиликать.

Вот такую фичу в mplayer, на уровне steganography с последующей возможностью доработать, повысить уровень. Зачем велосипед изобретать, всять сразу mplayer в качестве будующего crypto(stego)open gpg container maker-а.

Или может если мысль до Вас дошла, хотябы оформите её грамматно, я вижу с крипто Вы знакомы, и в mplayer девелопите, может сможете тикет протолкнуть. Хотелось бы видеть такое очень.

Я mplayer не трогал с 2005 года (или около того).

В обычном ПК-видео не 24 кадра в секунду, это слишком много. Поставьте mplayer на паузу, а дальше мотайте покадрово, нажимая на точку. Можете сами посчитать, сколько в среднем в секунде кадров. Я не проверял, но, имхо, штук 5, не больше.


Есть софт, который делает покадровую раскладку в картинки. Наверно, и открытый софт есть, не интересовался.


И можно будет грабать караваны.

Даже если говорить о подобном функционале (обработка видео), то это компетенция mencoder, а не mplayer. Проекты родственные, но это не одно и то же.

Р.S. Разговоры про 25-ый кадр попахивают шапочками из фольги.

5fps – это не видео, это слайдшоу которое невозможно смотреть без содрогания.
Фильмы на DVD выпускаются под 25 и 30 fps, 24 – это стандарт для кинопленки. И эти стандарты уже устарели. Я считаю что в будущем будут снимать 60fps stereo с разрешением 4k, фрагменты фильма Аватар уже доступны в таком формате, выглядит супер, настоящая революция в качестве видео.