А что плохого в закрытых библиотеках, если ключ в любом случае не извлекается? Какой смысл в подмене своей библиотекой одной из частей программно-аппаратного комплекса? Конечно, дело благородное, но с чего вы внезапно взяли, что написанная вами открытая библиотека будет корректно работать с токеном с точки зрения безопасности? Желательно, не с точки зрения интуиции.
В частности, упомянутый ранее CryptoPro Rutoken CSP является полноценным ПАК, где токен и программные библиотеки — равнозначно важные сущности.
Про УЭК, кстати, интересно. Что значит, «поддержать»? Он ведь проводит ряд защищенных процедур на неопубликованных протоколах (это не значит, что они плохие/кривые/проприетарные), а затем включает шифрованный канал.
Совсем забыл небольшой вопрос: если вы «отцепляете» токен от СКЗИ, то зачем вообще будут использоваться ГОСТ-алгоритмы? Купите обычные западные токены и работайте спокойно с виндовыми провайдерами.
Согласен. Когда читал, тоже соглашался далеко не со всем. Например, про тот же calloc, кажется, что его использование «всегда и везде» может привести к маскированию некоторых ошибок: например, забытую инициализацию какого-то поля структуры ненулевым значением.
Да и «первое правило» весьма сомнительное. Зачем автор целенаправленно его уточнил до «не используйте Си, если не надо»? Ведь это же частный случай более правильной и очевидной вещи: «Для решения задач используйте подходящие инструменты». В большинстве случаев, если использования Си можно избежать, значит, он там изначально и не был нужен.
Если мне не изменяет память, в 2014 году на ZeroNights ребята из ReCrypt рассказывали, что перевод последовательности инструкций в эту форму значительно упрощает процесс деобфускации.
Существуют разные способы хранения ключей на токене (в том числе и среди продуктов КриптоПро). В предыдущем комментарии речь шла о неизвлекаемых ключах.
Группа экспертов посмотрела на схему, поговорила, утвердила… А потом в течение 15 лет весь мир его изучал со всех сторон и не нашел существенных недостатков.
Просто оставлю это здесь.
Если коротко: Любой может создать криптосхему, которую сам не может взломать. То что десяток людей на хабре, которые заморочатся, не смогут этого сделать, не означает, что он нереально стойкий и может использоваться в жизни.
Вопросов несколько:
1) Зачем оно нужно, если есть AES и ГОСТ 28147-89? Даже стойкость уровня 128 еще много десятилетий будет адекватной.
2) Чем ваш алгоритм лучше приведенных по характеристикам, отличным от стойкости (производительность, схемотехническая сложность (простота)?
Я правильно понял из вашего профиля, что вы решили, что этот шифр более стойкий, чем AES? Почему? Потому что самостоятельно не удается его сломать? Потому что много всего намешано? Какое вообще обоснование подводится? Наличие лавинного эффекта?
Да, вроде, там хватает примеров.
Берется каркас программы, install, process, а дальше «получил — обработал — отправил». По личному опыту могу сказать, что наибольшее число проблем кроется в деталях реализации Java-машин конкретных производителей, чем в каких-то общих вещах, описанных в JC SDK. Все честно обещают полную, абсолютную реализацию API, а на деле, как говорится, всегда «есть некоторые нюансы».
Ну, во-первых, речь тут не о JavaCard, а о смарт-картах в общем. Тоже самое с примерами полностью описано в актуальных стандартах 7816, которые переведены на русский и носят статус ГОСТ.
Во-вторых, о JavaCard есть хорошая (правда, немного старенькая) переведенная книга Ж. Чен «Технология JavaCard для смарт-карт».
Все же, смарт-карты — это не гигантские вычислительные центры, особо много писать об интерфейсах работы с ними нельзя, потому что просто не о чем.
Тем не менее, статьи в качестве справочников для людей, которые только начинают гуглить об основах, подойдут.
Как уже указывали выше, это действительно нереально сложная задача, учитывая, что вы переименовали кучу классических понятий, причем совершенно непонятно, имеют ли они к интуитивно подходящим классическим хоть какое-то отношение. А наличие ссылок на людей, замеченных в связях с РАЕН, так и подавно сводит к нулю даже желание разбираться во всем этом.
Первый источник: труды некоего «Седьмого международного симпозиума». Путем непродолжительного гугления пришел к выводу, что речь, скорее всего, о «VII Международный симпозиум «Интеллектуальные системы» INTELS'2006»
Председатель организационного и программного комитета: Пупков К. А. — д.т.н., профессор, академик РАЕН, заведующий кафедрой РУДН (г. Москва).
Ну и подавляющее большинство всех ссылок, связанных с этим симпозиумом приводят к тому же самому РАЕН. Полагаю, все вопросы это сразу снимает.
Не всегда. Вон, посмотрите в сторону ДСЧ от Intel. Мы берем число из множества ничтожной мощности, суём его в AES в качестве ключа шифрования и, вуаля, получаем идеальную со статистической точки зрения последовательность. Ни один аналитик не подкопается. Тем более, если не знает, что именно за исходное множество у нас было, чтобы сузить объем материала для перебора.
Интересный подход, но кажется весьма избыточным. Если банку или интеграторам, которые там развернули СКЗИ, захочется выдавать вам «слабые» ключи или ключи с «бэкдорами», почему бы просто не использовать в качестве ДСЧ тупо константы? Ну или заведомо уязвимый ДСЧ вроде ЛКГ? Если злоумышленник является разработчиком средства защиты, то описанная в статье беда не самая страшная :)
В частности, упомянутый ранее CryptoPro Rutoken CSP является полноценным ПАК, где токен и программные библиотеки — равнозначно важные сущности.
Про УЭК, кстати, интересно. Что значит, «поддержать»? Он ведь проводит ряд защищенных процедур на неопубликованных протоколах (это не значит, что они плохие/кривые/проприетарные), а затем включает шифрованный канал.
Совсем забыл небольшой вопрос: если вы «отцепляете» токен от СКЗИ, то зачем вообще будут использоваться ГОСТ-алгоритмы? Купите обычные западные токены и работайте спокойно с виндовыми провайдерами.
Да и «первое правило» весьма сомнительное. Зачем автор целенаправленно его уточнил до «не используйте Си, если не надо»? Ведь это же частный случай более правильной и очевидной вещи: «Для решения задач используйте подходящие инструменты». В большинстве случаев, если использования Си можно избежать, значит, он там изначально и не был нужен.
Если коротко: Любой может создать криптосхему, которую сам не может взломать. То что десяток людей на хабре, которые заморочатся, не смогут этого сделать, не означает, что он нереально стойкий и может использоваться в жизни.
Вопросов несколько:
1) Зачем оно нужно, если есть AES и ГОСТ 28147-89? Даже стойкость уровня 128 еще много десятилетий будет адекватной.
2) Чем ваш алгоритм лучше приведенных по характеристикам, отличным от стойкости (производительность, схемотехническая сложность (простота)?
Берется каркас программы, install, process, а дальше «получил — обработал — отправил». По личному опыту могу сказать, что наибольшее число проблем кроется в деталях реализации Java-машин конкретных производителей, чем в каких-то общих вещах, описанных в JC SDK. Все честно обещают полную, абсолютную реализацию API, а на деле, как говорится, всегда «есть некоторые нюансы».
Во-вторых, о JavaCard есть хорошая (правда, немного старенькая) переведенная книга Ж. Чен «Технология JavaCard для смарт-карт».
Все же, смарт-карты — это не гигантские вычислительные центры, особо много писать об интерфейсах работы с ними нельзя, потому что просто не о чем.
Тем не менее, статьи в качестве справочников для людей, которые только начинают гуглить об основах, подойдут.
«сигнатурного алгоритма ГОСТ Р 34.10-2001 «Кузнечик»»
Какое отношение «Кузнечик» имеет к старому госту подписи? И что значит словосочетание «сигнатурный алгоритм шифрования»?
Председатель организационного и программного комитета: Пупков К. А. — д.т.н., профессор, академик РАЕН, заведующий кафедрой РУДН (г. Москва).
Ну и подавляющее большинство всех ссылок, связанных с этим симпозиумом приводят к тому же самому РАЕН. Полагаю, все вопросы это сразу снимает.