ГОСТ-криптография и GnuPG
Недавно в libgcrypt начали добавлять поддержку российских криптоалгоритмов.
На текущий момент есть симметричный шифр (28147-89) и хэш-функции (как старая,
так и Стрибог). ЭЦП будет позже. (Кстати, а ЭЦП по 34.10-94 кому-нибудь
реально нужна? А то влом реализовывать.)
1. Принимаются критика у улучшения.
2. Есть ли у кого-нибудь желание озаботиться дизайном/реализацией для поддержки
алгоритмов в OpenPGP? GnuPG использует именно libgcrypt в качестве
криптобиблиотеки.
комментариев: 12 документов: 3 редакций: 4
Кстати, а черновиком iso-шного приложения или s-box из него кто-нибудь может поделиться?
Раз речь идёт о национальном российском стандарте, почему бы ФСБ не взять и не разобраться детально в его работах, обобщив их на другие наборы S-блоков и опубликовав все результаты? Ну, чтобы, так сказать, дать окончательный ответ на все эти вопросы. В конце концов, при необходимости можно было бы связаться с Куртуа, узнать у него все детали, опущенные в его работе. ФСБ кто-то это запрещает всё? Или «прогибаться» не привыкли? Привыкли буром переть, используя административный ресрус? Тогда им на их место в ISO уже указали, всё заслуженно.
PGP есть PGP, зачем там S/MIME и PKI? Это почти ортогональные приблуды к идее PGP. Ну, и незачем переуслжнять стандарт, к большей безопасности это точно не ведёт.
А есть пруфы того, что он эти S-блоки взял из таких систем? Он об этом заявлял? Никто до сих пор не удосужился у него спросить, откуда он взял S-блоки?
Провокации здесь устраивают настоящие, бывшие, корпоративные и банковские, а unknown очень лаконично и выразительно подмечает дырявость их аргументации.
[флейм вырезан цензурой]
Кстати, должны быть или вот-вот появятся какие-то методические рекомендации ТК26. На данный момент у них на сайте опубликовано лишь разъяснения касающиеся шифрования в рамках схемы PBES2:
Сам лично запихнул бы в код пока что эти узлы замены. Из расчета, что для отладки и прогона проверочных примеров они сгодятся лучше других. После того как поделка начнет успешно проходить все юнит-тесты, тогда уже можно будет думать об использовании других s-блоков.
Да и именно с ними ГОСТ реализован в OpenSSL. Собственно переписывая код под GPL можно будет взять все тесты у OpenSSL.
комментариев: 12 документов: 3 редакций: 4
Пока жду ответа от Вернера про 34.10, посмотрел на libksba (библиотека, отвечающая за x.509/crl/cms в gpg). Мрак и ужас.
Не знал, что такое слово существует, впервые слышу.
lumag, зачем лично вам нужна поддержка ГОСТ в GnuPG/libgcrypt? Вы же вроде неглупый человек, могли бы заняться и более осмысленной деятельностью, чем добавка азиатских алгоритмов в стандарты. Неужели Mentor Graphics собралась реализовывать криптопродукцию на российский рынок?
комментариев: 12 документов: 3 редакций: 4
Существует, просто редко используется.
Осмысленной деятельности мне хватает на работе. А для развлечения я хочу выбирать то, что мне сейчас интересно.
комментариев: 9796 документов: 488 редакций: 5664
Обычно наоборот, ГОСТ для работы используют. В принудительном, так сказать порядке. А для развлечений что-нибудь другое. Но у всех, конечно, свои интересы. Если только для развлечений и отдыха
от осмысленной деятельности, то ничего плохого в этом нет.Практически без разницы будет ли это семейство ГОСТов или что-то ещё. При условии, что уже есть хотя бы один корректный и проверенный вариант реализации данного алгоритма в виде готового кода.
Даже если исходить сугубо с этих соображений, то позиция lumag более чем ясна и понятна.
Конечно, гораздо полезнее тратить свободное время на семью, друзей с родственниками или спорт. Однако бывают ситуации сродни обязательных жопочасов в офисе. Когда работы мало, а хочешь или не хочешь, но приходится «нести вахту» в обмен на регулярную зарплату с премией. И либо человек деградирует убивая время на зависание в интернетах, да социальных сетях. Либо занимается саморазвитием повышая квалификацию — читая литературу или возясь с вещами сродни libgcrypt.
комментариев: 9796 документов: 488 редакций: 5664
Так это всё понятно и замечательно, в резюме напишет полезные навыки, тот же Linux изначально "Just for fun" создавался.
Просто PGPru.com старается фокусироваться на тех теоретических направлениях и практических технологиях, которые могут быть полезны рядовым пользователям и небольшим группам для защиты своей информационной независимости, безопасности и анонимности.
То, что человеку дали возможность созвать единомышленников под это дело именно в плане ГОСТов в т.ч. и через PGPru.com вовсе не исключает, что активные участники PGPru считают такое дело не просто бесполезным, но и идущим в разрез с целями проекта. Хочет человек пиарить свой проект — пусть будет готов, что его цели могут встретить здесь неприятие. Более того вместо содействия, тому же Вернеру может быть отправлено письмо, ну если не с протестом, то с просьбой изолировать все недоверяемые алгоритмы в отдельную библиотеку, лишённую статуса доверяемой и официальной поддержки OpenPGP. По аналогии того, как ГОСТ выкинули из ядра Linux (crypto-API).
И дело не только в российских ГОСТах, некоторые азиатские алгоритмы шифрования, а также подозрительне ГПСЧ, протащенные в стандарты от АНБ США без конкурса, в свободном некоммерческом ПО также не хотелось бы видеть.
комментариев: 12 документов: 3 редакций: 4
Я очень спокойно и положительно отношусь к здравой критике.
Цели у меня простые – иметь возможность взаимодействовать с отечественными криптосервисами не только через 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-ник.
комментариев: 9796 документов: 488 редакций: 5664
ГОСТ там было ещё очень давно, но возможно не в официальном ядре, а ещё тогда, когда cryptoAPI выкладывалось на kernel.org отдельным патчем. Может перед тем, когда cryptoAPI включили в стандартное ядро, его оттуда и выкинули.
Алгоритм м.б. прозрачнее дальше некуда и никаких вопросов у криптографов не вызывать. Но, хотелось бы, чтобы существовали только алгоритмы, разрабатываемые в открытую. В этом плане российские и азиатские алгоритмы, претендующие на включение в стандарты, несут плохой пример в плане методики разработки. Да и с ECC в этом плане также плохо, поэтому Torproject отказался от официальных стандартов ECC, тянущихся от Цертикома/АНБ и перешёл на реализацию DJB.
Так они и рассчитывают продвигать алгоритмы путём навязывания. Вместо того, чтобы объявить такую практику неизбежным злом, достойным порицания и вынести поддержку нечестно проталкиваемых алгоритмов в отдельные библиотеки, вы включаетесь в игру на стороне проталкивателей против свободного криптосообщества. Предложен же разумный компромисс: придумайте способ того, чтобы по умолчанию это не ставилось, чтобы пользователи Linux-дистрибутива могли поставить поддержку таких алгоритмов только отдельными пакетами, не вшитыми намертво в стандарные утилиты и либы, не тащите это туда.
Если его не потащат в международные стандарты, то, возможно, никому и в голову не придёт его анализировать просто по факту его публикации. И в этом случае, качественного массового анализа может не быть — мало открытой публикации, он не разрабатывался открыто, проще его не использовать и также открыто не анализировать. Какой-нибудь новый метод криптоанализа будут опробывать в первую очередь на том, что широко применяется или что является перспективным.
Вот например, врезали 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 девелопите, может сможете тикет протолкнуть. Хотелось бы видеть такое очень.
комментариев: 12 документов: 3 редакций: 4
В обычном ПК-видео не 24 кадра в секунду, это слишком много. Поставьте mplayer на паузу, а дальше мотайте покадрово, нажимая на точку. Можете сами посчитать, сколько в среднем в секунде кадров. Я не проверял, но, имхо, штук 5, не больше.
Есть софт, который делает покадровую раскладку в картинки. Наверно, и открытый софт есть, не интересовался.
И можно будет грабать караваны.
Даже если говорить о подобном функционале (обработка видео), то это компетенция mencoder, а не mplayer. Проекты родственные, но это не одно и то же.
Р.S. Разговоры про 25-ый кадр попахивают шапочками из фольги.
Фильмы на DVD выпускаются под 25 и 30 fps, 24 – это стандарт для кинопленки. И эти стандарты уже устарели. Я считаю что в будущем будут снимать 60fps stereo с разрешением 4k, фрагменты фильма Аватар уже доступны в таком формате, выглядит супер, настоящая революция в качестве видео.