— SATtva (24/09/2013 20:27, исправлен 24/09/2013 20:28)   

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

Для официальной поддержки любых новых алгоритмов в OpenPGP нужен дополнительный IETF-стандарт с описанием параметров и резервированием идентификаторов, за примером отсылаю к стандарту^[link1] на Camellia (с асимметричными алгоритмами документ будет несколько сложнее). Всё это надо проталкивать через рабочую группу OpenPGP, так как именно этим людям реализовывать эти расширения в конечных приложениях. Пишите в список рассылки OpenPGP WG.

— lumag (24/09/2013 20:53)   
Я в курсе про IETF. Группа OpenPGP была закрыта ("concluded") в 2008 году. Хотя активность в списке рассылки продолжается, последние черновики идут не от имени группы,
а от конкретных людей.

Я опасаюсь, что в одиночку мне целиком создание спеки не потянуть. Поэтому и ищу поддержку.

— Гость (25/09/2013 00:05)   
Напоминает это^[link2] и это^[link3]. Так-то unknown уже сказал^[link4], что смысла в этом нет, были и другие посты на тему. Это нужно только для получения сертификаций и бюрократии, а для крипто самого по себе, по существу, нужен объективный стандарт, проанализированный сообществом.

Сильные шифры, которыми стоит пользоваться, IMHO, — AES и Twofish. Возможно, ещё Serpent. Короче, финалисты конкурса AES. А Camellia тоже не нужна, как и прочая экзотика.

— SATtva (25/09/2013 09:58)   

Я опасаюсь, что в одиночку мне целиком создание спеки не потянуть.

Берёте RFC5581 за шаблон и обновляете своими параметрами. Как я уже сказал, спецификация — не главное. В первую очередь Вам потребуется заинтересовать участников рабочей группы: она хоть и носит неформальный характер, но без поддержки, прежде всего, разработчиков GnuPG, спецификация будет просто валяться в архиве IETF. Если же формализация Вас не интересует, можете использовать зарезервированные в RFC4880 private-идентификаторы, а сами алгоритмы добавить в GnuPG в виде подключаемых библиотек, как это делали с IDEA.

— Гость (26/09/2013 02:48)   

Недавно в libgcrypt начали добавлять поддержку российских криптоалгоритмов.

С каким именно набором S-блоков?
Насколько помнится в RFC 4357 живет большая подстава. И не соответствует требованиям предъявляемым ФСБ к реализации ГОСТов.
В общем, не пожалейте времени на общение с теми, кто сертифицировал и помнит нюансы требований к реализации этих алгоритмов.

— Гость (26/09/2013 03:15)   
Набор S-блоков в RFC 4357 был придуман КРИПТО-ПРО, у которой вроде бы как нет и не было^[link5] ни одного продукта или библиотеки сертифицированных до гостайны. Придуман этот набор был для того, чтобы начать играть в совместимость с решениями других производителей. В секторе гражданских систем защиты информации, не содержащих сведений, составляющих государственную тайну.
Потому ряд продуктов других российских компаний имеют два режима. Один из которых сводится к поддержке этого самого RFC 4357. Для совместимости с теми решениями других компаний, которые имеют более низкий уровень сертификации.

— lumag (27/09/2013 00:36, исправлен 27/09/2013 00:37)   

Пока что поддерживаются только S-блоки из примера в ГОСТ Р 34.11-94.
Как только придумаю, как именно удобно передавать настройки S-блоков
из вышележащего кода, можно будет добавить остальные блоки.
Основные направления интереса – GnuPG (S/MIME, OpenPGP), GnuTLS (PKI,
TLS под вопросом).

— Беня (27/09/2013 04:15)   

Это массив из восьми uint64.
И если на С++, то
typedef uint64_t( t_sblock_array )[ 8 ]; t_sblock_array sblock_table = { 0x4A92D80E6B1C7F53, // S0: 4 10 9 2 13 8 0 14 6 11 1 12 7 15 5 3 0xEB4C6DFA23810759, // S1: 14 11 4 12 6 13 15 10 2 3 8 1 0 7 5 9 0x581DA342EFC7609B, // S2: 5 8 1 13 10 3 4 2 14 15 12 7 6 0 9 11 //... и так до 8-го строки таблицы }; // и декларейшн функции принимающей S-блоки одним из параметров error_t enc_gost_impl( ..., const t_sblock_array& s_blocks, ... );

— lumag (27/09/2013 05:52)   
Беня, я в курсе.

— SATtva (27/09/2013 07:51)   
Я вижу только один вменяемый способ: отдельный идентификатор симметричного алгоритма под каждый набор S-блоков.

— Беня (28/09/2013 16:49)   

Я вижу только один вменяемый способ: отдельный идентификатор симметричного алгоритма под каждый набор S-блоков.

Его нельзя использовать в GnuPG. Потому что наборов S-блоков для ГОСТа существует от шестнадцати и более:

• десять утверждены Государственной службы специальной связи и защиты информации Украины
• один утвержден в Белоруссии (СТБ П 34.101.50-2012)
• четыре изобретены КриптоПро и отлиты в RFC4357
• один подан российским техническим комитетом по стандартизации на ISO/IEC 18033-3 (определен в 1-м рабочем проекте Дополнения 1)
• возможно есть еще, отличные от этих и используемые для защиты российской гостайны

При таком зоопарке имеет смысл брать лишь iso-шный вариант. Например, в своих работах Куртуа использовал набор S-блоков «хрен поймешь откуда взятый». За что и был подвергнут жесткой критики со стороны сообщества. Вполне логично, что в следующий раз он и ему подобные возьмут уже iso-шный вариант. Тем самым в GnuPG будет использован наиболее часто колупаемый вариант.

GnuPG живет в своем собственном мирке и нет вопроса совместимости с другими криптографическими продуктами российского, украинского или белорусского происхождения. Потому нет надобности зашивать все ныне известные наборы S-блоков.

— unknown (28/09/2013 21:00)   

GnuPG живет в своем собственном мирке и нет вопроса совместимости с другими криптографическими продуктами российского, украинского или белорусского происхождения.

[off]
Fix по поводу причины и следствия:
Продукты российского, украинского или белорусского происхождения живут в своём мирке, поэтому у GnuPG нет вопроса совместимости с ними.
[/off]

— Гость (28/09/2013 22:56)   

Тусовка GnuPG — это толпа криптопанков. Долго и нудно ложивших с прибором как на промышленные стандарты сродни PKCS, так и на существующие де-факто. Достаточно вспомнить сколько лет GnuPG огораживалось ото всего мира убогим OpenPGP и когда начали прикручивать поддержку S/MIME и PKI.

— gyhsal (29/09/2013 00:15)   

Кстати, а ЭЦП по 34.10-94 кому-нибудь реально нужна? А то влом реализовывать.

А кому оно может быть надо, когда есть уже ГОСТы 34.10-2012 и 34.11-2012?

— lumag (29/09/2013 00:55, исправлен 29/09/2013 01:09)   

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

— Гость (29/09/2013 07:11)   

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


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


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


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

— Гость (29/09/2013 14:51, исправлен 29/09/2013 16:17)   

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

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

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

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

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

— lumag (01/10/2013 03:01)   
Набросал на коленке сайт^[link8].

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

— Гость (01/10/2013 06:44)   

Add support for GOST encipherment in GnuPG ∎^[link9]

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

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

— lumag (01/10/2013 12:01)   


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

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

— unknown (01/10/2013 16:28, исправлен 01/10/2013 16:29)   

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

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

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

— unknown (01/10/2013 21:21, исправлен 01/10/2013 21:25)   

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

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

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

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

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

— lumag (01/10/2013 21:59)   
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-ник.

— unknown (01/10/2013 22:24, исправлен 01/10/2013 22:41)   

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

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

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

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

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

— Гость (02/10/2013 01:17)   
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 девелопите, может сможете тикет протолкнуть. Хотелось бы видеть такое очень.

— lumag (02/10/2013 01:31)   
Я mplayer не трогал с 2005 года (или около того).

— Гость (04/10/2013 06:00)   

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


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


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

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

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

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

— Гость (04/10/2013 07:38)   

Я имел в виду обычное HD видео. Смотрится вполне прилично.

— SATtva (04/10/2013 08:18)   

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

В любом нормальном видеоряде 24-30 fps. Надо проверять не на покадровой перемотке, которая неизвестно как работает, а по диагностическому выводу кодека: запустите видео в том же мплеере и ищите строку VIDEO, где будет что-нибудь типа
VIDEO: [CODEC] XXXXxYYY NNbpp 25.000 fps NNNN kbps (NNN kbyte/s)

— unknown (04/10/2013 09:47, исправлен 04/10/2013 09:49)   

Может тему с мплейером создать вообще в оффтопике?

[off]
Покадровый просмотр вроде не имеет отношения к стеганографии, а разобрать видео на кадры можно через mplayer:

jpeg

Output each frame into a JPEG file in the current directory. Each file takes the frame number padded with leading zeros as name.

tga

Output each frame into a Targa file in the current directory.

EXAMPLE:

mplayer video.nut -vf format=bgr15 -vo tga

Т.е. можно покадрово выводить в JPEG, PNG, PNM, TGA, также как и обратно собирать из них видео через mencoder, отклеивать и приклеивать звук и т.д.
[/off]

— Гость (05/10/2013 03:22)   

OK, посмотрю.


Если кому-то интересно, у меня в загашнике есть скрипт на шелле, который mencoder'ом перекодирует видео, отснятое фото/видеокамерой, уменьшая его размер в 12.5 раз и при этом сохраняя качество. Кодируется в H264 — это вроде самый хорошо сжимающий кодек, хоть и не вполне свободный (но с его поддержкой в Linux проблем нет). На топовых процессорах один мегабайт исходного видео пережимается примерно 1 сек. По времени уже не помню затраты, кажется, оно в несколько раз больше, чем время проигрывания. Если кому-то интересно, могу выложить.

— Гость (23/10/2013 07:10)   

Осталось понять, почему сайт госуслуг (персональные данные) до сих пор по ГОСТ-у не шифрует. Или тот AES_256_CBC в исполнении openssl, что моим браузером используется – он сертифицирован? :)^[link11]

— Гость (23/10/2013 07:46)   

ГОСТ опубликован как IETF RFC 4357. По итогам рассмотрения его международной криптотусовкой нашли в нем только то, что и так давно известно: что устойчивость сильно зависит от вектора инициализации. Но это известная штука, поэтому во всяких "государственных" предложениях кроме собственно спецификации алгоритма есть еще и ограничения на вектор инициализации, которые вот эти проблемы на 100% и снимают. ∎^[link12]

Это правда что ли? Какой бы ответ на это дала современная криптография?

— unknown (23/10/2013 09:58)   

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

Для потоковых шифров, в которых нет стандартных входов для IV (как в RC4) этой фразе ещё можно придумать какой-то смысл.

— Гость (24/10/2013 00:27)   
А разве IV не всегда должен выбираться случайно?

— lumag (24/10/2013 00:42)   


Нет. GCM, например, специфицирует, что случайный IV недостаточно надежен. Если два IV совпадут, можно получить ключ (или часть информации о ключе). Рекомендуют, вместо этого, например, использовать счетчик.

— unknown (25/10/2013 09:53)   
А в некоторых режимах, наоборот, нельзя использовать счётчик, только случайный IV.

— lumag (25/10/2013 19:39)   
unknown, я не настолько специалист. Где именно требуются случайные IV? Или Вы про разборки с BEAST?

— unknown (25/10/2013 22:08)   
В простейшем CBC.
CBC-(IV-счётчик) вроде на первый взгляд некритичен, но в ряде случаев — нельзя, это не касается именно BEAST.

— Кстати (01/11/2013 10:11)   
Тексты ГОСТ: ГОСТ Р34.11-94^[link13] и ГОСТ 28147-89^[link14]

— ржунимагу (09/11/2013 10:09)   

/comment3197^[link15]: Каллас обратился ко мне напрямую с вопросом, сможем ли мы (pgpru.com), если в итоге группа придёт к заключению добавлять ГОСТы в стандарт, оценить предложенные спецификации OpenPGP на предмет корректности, соответствию ГОСТам и требованиям отечественных госструктур. Затея того стоит.

Прошло 8 лет^[link16]:

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

/comment3207^[link17].

И вновь продолжается идёт всё по кругу. И Ленин Unknown... та-а-кой молодой! И старый октябрь позади. :-(

— SATtva (09/11/2013 10:17)   
Мне от Ваших вбросов тоже смешно. Можно подумать, цели проекта и его участников отлиты в граните и за 8 лет не способны в какой-то части существенно измениться.

— Гость (09/11/2013 10:41)   
SATtva, я прекрасно всё понимаю, но... когда на такое натыкаешься, это очень ржачно читать 8 лет спустя. Ничего не имею против. Считайте, что это такой местный вид винтажного юмора на 8-летних баянах. :)

P.S. Коллизионная^[link18] нестойкость^[link19] — это тоже весело. ☺

— aXe1 (06/02/2014 13:15)   
С начала 2013 г. в России начали выдавать УЭК^[link20] с возможностью записи на нее квалифицированной ЭЦП. Я понимаю, что без гос.сертификации (как у Крипто-Про УЭК) – юридической значимости не будет, однако может быть и гражданская заинтересованность. Например, возможность удостоверить свою личность для сообщества, подписав свой основной PGP ключ ЭЦП, выданной государством.

Сейчас получив эту супер-пупер квалифицированную ЭЦП – единственное, что может обычный пользователь с ее помощью – это заходить на портал гос.услуг. Для подписывания любых документов – надо покупать отдельный, узко-специализированный (и ни с чем аналогичным не совместимый!) софт у узкого числа фирм, получивших сертификацию (остальным, похоже, вообще не интересно это). С шифрованием файлов, насколько знаю еще хуже.

Если будет хоть какая-нибудь пригодная для ежедневного использования реализация – это может стать хорошим толчком в сторону повсеместного внедрения криптографии в России. А также может сдвинуть процесс искоренения vendor-lock'ов в отечественной криптографии.

Ждать, что в России начнут использовать международные стандарты на гос.уровне – глупо. Будь реализация, я бы с удовольствием скинулся на сертификацию ОТКРЫТОЙ реализации ГОСТ-ов (да и поучаствовал тоже), если бы это приблизило возможность использования электронного документооборота взамен бумажному (без vendor-lock'ов и немеренного количества сопроводительной БУМАЖНОЙ волокиты). Этот путь кажется реалистичнее, чем ожидание, когда государство по своей инициативе захочет сделать по-человечески.

— unknown (06/02/2014 14:17, исправлен 06/02/2014 14:21)   

Ждать, что в России начнут использовать международные стандарты на гос.уровне – глупо.

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

А также может сдвинуть процесс искоренения vendor-lock'ов в отечественной криптографии.

Сомнительно, в условиях когда весь смысл существования гражданской госкриптографии — это локи от государственных вендоров.

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

Оно всё-равно не даст. Да и не нужно, чтобы давало. Если вы только не занимаетесь в России электронной коммерцией или чем-то таким. Для чего-кого нужны криптопродукты от государства?

Сайт посвящён вопросам безопасности и анонимности отдельных лиц или малых любительских сообществ. Государственную, корпоративную и коммерческую безопасность здесь стараются не обсуждать^[link21].

— aXe1 (06/02/2014 17:30)   

Ждать, что практическая госкриптография кому-то станет интересна хоть с какими стандартами — тоже.

Возможность полностью отказаться от бумажных документов, в т.ч. чтобы суд принимал их – не интересно разве?

Сомнительно, в условиях когда весь смысл существования гражданской госкриптографии — это локи от государственных вендоров.

Смысл в том, чтобы был "lock" на алгоритмы и протоколы, принимаемые государством, а не на реализацию их.

Оно всё-равно не даст. Да и не нужно, чтобы давало. Если вы только не занимаетесь в России электронной коммерцией или чем-то таким. Для чего-кого нужны криптопродукты от государства?

Удостоверение личности. Как пример: на всяких key-sign party обычно сверяют имя и фамилию с тем, что в бумажном паспорте, а так можно сверять без личной встречи с помощью эцп.
Еще примеры использования: взять расписку с должника, написать на работе заявление на отпуск, написать ребенку справку в школу/садик. Вообщем-то везде где мы лично встречаемся только для того, чтобы отдать подписанную бумажку должно быть эцп и e-mail (или сервис какой-нибудь).

— unknown (06/02/2014 17:58)   

Всякие применения криптографии для обслуживания госбюрократии будут госбюрократичными by-design.

Еще примеры использования: взять расписку с должника, написать на работе заявление на отпуск, написать ребенку справку в школу/садик. Вообщем-то везде где мы лично встречаемся только для того, чтобы отдать подписанную бумажку должно быть эцп и e-mail (или сервис какой-нибудь).

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


Если это для государства, то будет «лок» от государства; если из обслуживания государственных интересов можно извлекать прибыль, то «лок» всё равно будет от структур, имеющих связи с государством.


"Why the Web of Trust Sucks"^[link22]


13 причин не прибегать к использованию PGP^[link23].