Гост

Шифруем по-русски, или отечественные криптоалгоритмы

01.12.2020 18:05:13 |

Автор: admin

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

Из новостей

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

До конца 2020 года планируется закончить создание национального удостоверяющего центра структуры, которая будет выдавать сайтам вРунете отечественные цифровые сертификаты, пишет Медуза. Также, по данным этого издательства отечественные цифровые сертификаты будут использовать криптоалгоритмы Магма и Кузнечик. Кроме того, отечественные алгоритмы шифрования по требованию Центробанка станут обязательными к использованию в платежных системах уже с 2024 года, пишет РБК.

Добавим к этому новость от газеты Коммерсантъ, в которой Магма и Кузнечик упоминаются в контексте тестируемых алгоритмов для использования в виртуальных сим-картах eSim.

Упомянутые выше и другие основные алгоритмы, используемые в отечественной криптографии стандартизованы и описаны в ГОСТах.

Направления ГОСТов

Отечественная криптография базируется на четырех основных объектах, которые мы рассмотрим далее.

Цифровая подпись

ГОСТ 34.10-2018 описывает алгоритмы формирования и проверки электронной цифровой подписи с помощью операций в группе точек эллиптической кривой и функции хеширования. Длины секретного ключа 256 бит и 512 бит.

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

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

Эллиптической кривой над конечным простым полем F_p , где p>3 , называется множество точек (x, y) , $x,y\ \epsilon\ F_p$ , удовлетворяющих уравнению (в форме Вейерштрасса) $y^2 = x^3 + ax + b (mod\ p)$ , где $4a^3+27b^2 \neq0$ , $a,\ b\ \epsilon\ F_p$ .

Альтернативный способ задать эллиптическую кривую

Отметим, что эллиптическую кривую можно задать уравнением не только в форме Вейерштрасса. Относительно новым способом задания эллиптической кривой является уравнение в форме Эдвардса $x^2 + y^2 = 1+dx^2y^2, d\ \epsilon \ F_p\backslash \{ 0,1 \}$ .

Суммой точек , эллиптической кривой называется точка (x_3,y_3) , координаты которой определяются, как $x_3 = \lambda^2 -x_1 -x_2(mod\ p)$ , $y_3 = \lambda^2(x_1 -x_3) -y_1(mod\ p)$ , где $\lambda = \frac{y_2 - y_1}{x_2-x_1} (mod\ p)$ .

Точка эллиптической кривой C = kP , может быть определена через сумму точек C = P+P+...+P .

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

Алгоритмы формирования и проверки электронной цифровой подписи.

Подпись создается по следующему алгоритму.

входные данные: сообщение и закрытый ключ подписи .

к сообщению применяется хеш-функция(Стрибог) и вычисляется хеш-код сообщения h=h(M) , отметим, что хеш-код это строка бит.

определяется число $e = \alpha(mod\ q)$ , где $\alpha$ целое число, которое соответствует двоичному представлению хеш-кода . Причем если $\alpha(mod\ q) = 0$ , то принимается за 1.
это порядок порядок циклической подгруппы группы точек эллиптической кривой, который является одним из параметров цифровой подписи. Также среди параметров есть это базовая точка подгруппы.

на основе случайно сгенерированного целого числа k, 0<k<q , это число называют секретным ключом. Затем вычисляется точка на эллиптической кривой C = kP . Точка имеет координаты (x_c,y_c) .

из координаты точки на эллиптической кривой и преобразования хеша вычисляется электронная подпись (r, s) , где $r = x_c (mod\ q),\ s = (rd+ke)(mod\ q)$ . Если либо , либо равняется 0, то нужно вернуться к предыдущему шагу.

выходные данные: цифровая подпись (r, s) которую добавляют к сообщению.

Теперь перейдем к алгоритму проверки подписи.

входные данные: сообщение c цифровой подписью (r, s) и ключ проверки подписи

полученная цифровая подпись проходит первичную проверку, если проверка не пройдена, то есть не выполнены неравенства $0<r<q,\ 0<s<q$ , то подпись неверна.

вычисляется хеш-код сообщения h=h(M) , опять же с помощью алгоритма Стрибог.

определяется число $e = \alpha(mod\ q)$ , где $\alpha$ целое число, которое соответсвует двоичному представлению хеш-кода . Причем если $\alpha(mod\ q) = 0$ , то принимается за 1. Затем определяется $\nu = e^{-1}(mod\ q)$ .

вычисляется точка эллиптической кривой $C = s\nu P -r\nu Q$ , из которой получается $R = x_c (mod\ q)$ .

если r = R , то подпись верна

выходные данные: подпись вена/неверна

Хеш-функция

ГОСТ 34.11-2018 посвящен функции хеширования. В данном документе содержится описание алгоритма вычисления хеш-функции, известной из предыдущих версий стандарта, как Стрибог.

Стрибог принимает на вход сообщение произвольной длины, которое впоследствии разбивается на блоки размером 512 бит(с дополнением блоков при необходимости). После чего входные данные преобразуются в хеш-код фиксированной длинны 256 или 512 бит.

Подробное описание алгоритма вместе с разбором используемых в нем преобразований можно найти в статье @NeverWalkAloner.

Шифры

ГОСТ 34.12-2018 охватывает блочные шифры. Именно в этом ГОСТе описаны алгоритмы шифрования Кузнечик и Магма алгоритмы блочного шифрования с длинами шифруемых блоков 128 бит и 64 бита соответсвенно и длиной ключа шифрования 256 бит у обоих.

Шифрование блока открытого теста Кузнечиком происходит в 10 раундов, для каждого раунда из исходного ключа шифрования генерируется пара раундовых ключей, в каждом раунде проходят стадии подстановки и перестановки (перестановка вызывает особый интерес для криптоанализа алгоритма).

Приведем упрощенную схему работы Кузнечика при зашифровании.

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

@sevastyan01 в своей статье подробно описал алгоритм Кузнечик.

Зашифрование блока Магмой проходит в 32 раунда, для каждого раунда из исходного ключа шифрования генерируется раундовый ключ, причем алгоритм генерации ключей отличается от генерации ключей в Кузнечике.

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

Режимы работы шифров

ГОСТ 34.13-2018 содержит описание следующих режимов работы блочных шифров.

Режим простой замены

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

Расшифрование происходит аналогичным образом. Причем если при зашифровании было применено дополнение, то при расшифровании применяется обратная операция.

Режим гаммирования

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

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

Если общая длина гаммы не кратна длине блока, то последний блок гаммы усекается до размера блока. Блоки гаммы отличны друг от друга и имеют псевдослучайных характер.

Режимы гаммирования с обратной связью: по выходу, по шифротексту

Два режима помещены в один пункт, так как они похожи между собой. В данных режимах при зашифровании выходные данные процедуры шифрования, либо сам шифротекст в случае обратной связи по шифротексту, подаются на вход следующей процедуре шифрования и так далее.

Отличие режимов можно увидеть на схеме.

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

Режим простой замены с зацеплением

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

Режим выработки имитовставки

При работе в данном режиме создается зависящий от всего текста блок, который предназначен для проверки наличия в шифротексте искажений.

Каждый из стандартов действителен с 1 июня 2019 года в соответствии с приказом Федерального агентства по техническому регулированию и метрологии. Актуальные ГОСТы наследуют разработки, прописанные в предыдущих версиях.

Реализации алгоритмов ГОСТов

@ru_crypt в своей статье собрал множество вариантов реализации ГОСТовских алгоритмов на любой вкус.

Интерес к таблице подстановок

Рассмотрим ГОСТ 34.10-2018. В алгоритмах формирования и проверки цифровой подписи на начальных шагах используется хеш-функция Стрибог, которая определена в ГОСТ 34.11-2018.

Заглянем теперь в ГОСТ 34.12-2018. В данном документе в качестве параметра алгоритма Кузнечик для нелинейного биективного преобразования приводится таблица подстановок

$\pi$ . Эта же таблица приведена в ГОСТ 34.11-2018, то есть используется и при хешировании.

Таблица $\pi$ задает единственное нелинейное преобразование в алгоритме шифрования, которое значительно усложняет взлом шифра. То есть функция подстановки особенно важна для устойчивости шифра к взломам.

Разработчики Кузнечика и Стрибога утверждают, что сгенерировали таблицу $\pi$ случайным образом. Однако в ряде работ был проведен криптоанализ таблицы подстановок и выявлено несколько способов ее генерации, причем не случайным образом.

Статьи с алгоритмами генерации таблицы $\pi$ :

Reverse-Engineering the S-Box of Streebog, Kuznyechik and STRIBOBr1 Alex Biryukov, L eo Perrin, and Aleksei Udovenko

Exponential S-Boxes: a Link Between the S-Boxes of BelT and Kuznyechik/Streebog Lo Perrin and Aleksei Udovenko

Partitions in the S-Box of Streebog and Kuznyechik Lo Perrin

В конце каждой из статей приведены алгоритмы генерации таблицы подстановок, которые можно запустить в оригинальном виде с помощью SageMath.

Заключение

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

Подробнее..

Категории: Информационная безопасность , Алгоритмы , Криптография , Шифр , Цифровая подпись , Гост , Кузнечик , Магма , Стрибог

Типы линий и где они хранятся

18.06.2021 10:22:12 |

Автор: admin

Линии окружают нас повсюду, они не раз спасали людям жизнь. Каким образом? Вспомним хотя бы буквенные коды в азбуке Морзе каждая буква азбуки представляет собой определенную последовательность точек и тире, и, если с помощью этих символов написать повторяющуюся последовательность букв, получим линию. Пример на рис. 1.

Рис. 1. Азбука Морзе и пример линии

Также и при проектировании невозможно представить чертеж, не содержащий разных (по весу, цвету, начертанию) линий. Поэтому тема применения линий и выбора мест их хранения в среде проектирования всегда будет актуальной. Разберемся, как это устроено в nanoCAD.

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

nanoCAD предлагает множество разных типов линий: линии из ГОСТ 2.303 уже предустановлены, есть и файл с линиями стандарта ISO. Кроме того, здесь можно создавать любые, самые нестандартные типы линий, причем это не отнимет много времени и сил. Чтобы в этом убедиться, погрузимся в волшебный мир линий и создадим две довольно сложные линии (рис. 2).

Рис. 2. Наша цель

Впрочем, обо всем по порядку.

Все линии, используемые в nanoCAD, хранятся в папке SHX по пути C:\ProgramData\Nanosoft\nanoCAD x64 21.0\SHX и собраны в файлах с расширением *.lin. Открыть файлы можно в любом текстовом редакторе. Каждая линия задается собственным уникальным именем, в описании содержится информация о составляющих (штрихах, формах, символах). В одном lin-файле может храниться достаточно большое количество типов линий. По умолчанию в состав поставки входят следующие файлы:

GOST 2.303-68.lin (содержит линии, соответствующие ГОСТ. Передавать этот файл следует вместе с файлом форм GOST 2.303-68.shx);
ncad.lin (содержит линии, соответствующие международному стандарту ISO. Передавать этот файл следует вместе с файлом форм ltypeshp.shx).

Текущая на данный момент линия будет применяться практически во всех инструментах nanoCAD из группы Черчение: окружности, эллипсы, многоугольники, сплайны можно рисовать абсолютно любой линией (рис. 3).

Рис. 3. Способы применения линий в nanoCAD

Посмотреть, какая линия является текущей, а также переключиться на другую можно на функциональной панели Свойства, на вкладке Главная в группе Свойства, или в диалоговом окне Типы линий (вкладка Главная группа Оформление Типы линий) рис. 4.

Рис. 4. Просмотр текущего типа линии

Здесь важно отметить, что линии могут храниться в самих dwg-файлах. Те из них, что уже имеются в этих файлах (на панели свойств), на самом деле были загружены в шаблон *.dwt, на основе которого и был создан dwg-файл. Поэтому при передаче чертежей, в которых имеются уникальные линии, можно не волноваться об их сохранности если, как вы, наверное, уже догадались, в линиях не используются уникальные формы или шрифты.

Загрузить новую линию в текущий документ можно двумя способами (рис. 5-6):

через панель свойств, в выпадающем меню Загрузить;

Рис. 5. Способ 1: панель свойств

через диалоговое окно Типы линий.

Важно! Чтобы загрузить сложные линии, нам нужно предварительно не только положить в папку SHX все используемые формы, но и создать текстовые стили, которые прописаны в линии. Узнать о том, какие текстовые стили используются в линии, можно с помощью любого текстового редактора.

Рассмотрим диалоговое окно Типы линий поподробнее. Здесь всё достаточно просто. В правой верхней части окна располагаются кнопки для создания, удаления, редактирования, импорта и экспорта линий.

Рис. 6. Способ 2: диалоговое окно

Центральная часть представляет собой небольшую таблицу из трех столбцов:
Статус отображение текущей линии. Текущую линию можно установить переключением галочки.
Имя отображение имени линии. Здесь имя можно отредактировать, но переименование типа линии изменит его описание только в текущем чертеже в lin-файле название останется прежним.
Пояснение текстовое описание типа и примерное отображение линии.

Типы линий По слою, По блоку, Сплошная удалить или переименовать нельзя. Также нет возможности удалить текущий тип линии.

В графе Подробности (она располагается в нижней части окна) можно настроить работу с масштабами:

Масштаб в единицах пространства листа полезная опция при использовании нескольких видовых экранов.
Глобальный масштаб задание глобального масштабного коэффициента для всех типов линий. Установленный глобальный масштаб относится ко всем вновь создаваемым и уже созданным линиям. Выделив линию, его можно проследить в масштабах символов. Глобальный масштаб удобно использовать при нестандартном масштабе линий.
Текущий масштаб задание масштабного коэффициента для вновь создаваемых линий. Результирующий коэффициент масштаба будет равен произведению глобального и текущего масштабов.

Создавать линии в nanoCAD можно двумя способами:

через встроенный редактор типов линий;
через любой текстовый редактор.

Конечно, мы опробуем оба способа. Линию Ньют создадим через встроенный, а линию Нюхль через текстовый редактор.

Рассмотрим, из чего будут состоять линии.

Линия Ньют (рис. 7).

Рис. 7. Состав линии Ньют

Линия Нюхль (рис. 8).

Рис. 8. Состав линии Нюхль

Штрих тире любой положительной длины.
Пробел тире любой отрицательной длины (расстояние между соседними элементами).
Точка штрих нулевой длины.

Вне зависимости от того, какой способ используется, все формы и шрифты должны быть у нас готовы/установлены, также необходимо заранее создать нужные текстовые стили. Текст Fantastic Lines (имя текстового стиля Fantastic Beasts) набран шрифтом Harry Potter, его можно найти на просторах интернета Создание формы SEGMENT было разобрано в статье Штриховки, файлы форм, или Как прикоснуться к искусству. В линии Нюхль используется шрифт romanc.shx с именем текстового стиля NIFFLER.

Давайте теперь наполним наш чемоданчик нужными формами!

Форма WAND.

Первое, что нужно волшебнику, своя волшебная палочка. Конечно, ее всегда можно одолжить у друзей или взять у автора, но, согласитесь, намного приятнее сделать собственную. Тем, кто уже знаком с формами (см. статью Штриховки, файлы форм, или Как прикоснуться к искусству), создать ее не составит особого труда. Моя волшебная палочка будет выглядеть достаточно просто примерно так же, как у Ньюта Саламандера из Фантастических тварей (рис. 9).

Рис. 9. Форма Волшебная палочка

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

*1, 42,WAND00A, (3, 042),               ;дуга радиусом 3мм004, 16,                     ;умножаем длину следующего отрезка на 16080,                         ;отрезок длиной 128 с учетом масштаба003, 16,                     ;делим длину следующего отрезка на 1600A, (1, 064),               ;дуга радиусом 1мм008, (-128, 4),              ;отрезок со смещением00A, (3, 022),               ;дуга радиусом 3мм00A, (3, -042),              ;дуга радиусом 3мм; возвращаемся в предыдущую точку00B, (0, 3, 0,10, -022),     ;дробная дуга  00B, (253, 0, 0, 10, -002),  ;дробная дуга  004, 15,                     ;умножаем длину следующего отрезка на 15040,                         ;отрезок длиной 60мм003, 15,                     ;делим длину следующего отрезка на 16044,                         ;отрезок длиной 4мм04C,                         ;отрезок длиной 4мм; возвращаемся в предыдущую точку030,                         ;отрезок длиной 3мм044,                         ;отрезок длиной 4мм0                            ;конец определения формы

Форма NIFFLER.

Далее создаем своего любимца, у меня это Нюхль маленький пушистый зверек с вытянутой мордочкой (рис. 10).

Рис. 10. Форма NIFFLER

В качестве тренировки попробуйте создать зверька самостоятельно. Код формы ниже.

*1, 89,NIFFLER014, 008, (-10,1), 034, 00A, (10, 004), 002, 003, 2, 010, 003, 5, 020, 074, 004, 10, 034, 001, 00C, (-14, -7, 126),02A, 040, 022, 00C, (6,-1,38), 01D, 040, 008, (1, 3), 002,003, 2, 018, 024, 004, 2, 001, 00C, (5, -4, 38), 0F0, 080,                   002, 0E8, 074, 001, 00A, 3, 000, 002, 018, 024, 003, 5, 014, 004, 5, 001, 00C, (-3, -5, 86),               002, 0F8, 0E8, 0F4, 024, 001, 00C, (6, -10, 30), 002, 094, 068, 001,00C, (3,-14,66),0

Нюхль падок на все блестящее, обязательно стянет любой сверкающий предмет, какой ему только попадется. Порадуем его сокровищами монетками.

Форма COIN.

Рис. 11. Форма COIN

Эта форма похожа на монету и достаточно проста в написании (рис. 11).

Код формы представлен ниже.

*1, 21,COIN00A, (6, 000), 002, 028, 001,00A, (4,000),002, 028, 024,001, 048, 008, (2,-4),008, (2,4), 0

Чемодан для путешествий собран. Приступим к созданию линий!

Создание линии Ньют через встроенный редактор.

Чтобы открыть встроенный редактор, необходимо в диалоговом окне Типы линий выбрать линию и нажать кнопку Редактировать (рис. 12).

Рис. 12. Встроенный редактор линий

Строка Тип, расположенная в правой части окна редактора, позволяет выбрать тип элемента линии: штрих/пробел. В строке Длина выставляем + для штриха и - для пробела. В этом же окне указываем, текст это или форма, и задаем параметры элемента. Далее создается новый элемент.

Все параметры раздела Геометрия приведены ниже, в таблице Параметры вставки форм и текста.

В нижней части окна прописывается код линии.

При всем удобстве и простоте этого инструмента его возможности ограничены количеством создаваемых элементов линии. Через встроенный редактор можно создать линию не более чем с 12 элементами, включая пробелы. Во многих случаях большего и не требуется, но при необходимости (допустим, для создания нашей линии Нюхль) линию можно создать через текстовый редактор.

Создание линии Нюхль через текстовый редактор.

Для более безболезненного переноса линий в будущие версии nanoCAD, а также для того чтобы избежать декодирования текста, рекомендуется добавлять собственные линии в раздел Пользовательские типы линий файла ncad.lin (файл расположен по пути: C:\ProgramData\Nanosoft\nanoCAD x64 21.0\SHX) (табл. 1).

Таблица 1. Структура содержания файла *.lin

номер строки	пояснение	пример
0	Комментарии через знак ;	;; Пользовательские типы линий
1	Первая строка уникальное имя и пояснение (визуализация)	*Нюхль, Нюхль и Монеты
2	Вторая строка начертания (через запятую, без пробелов)	A,10,-10,["Нюхль",NIFFLER,S=5],-30,10, -55,[NIFFLER,NIFFLER.shx,S=1], -20,[COIN,COIN.shx,S=1,Y=4],-15,[COIN,COIN.shx,S=1,Y=4],-15,[COIN,COIN.shx,S=1,Y=4],-5

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

Рис. 13. Примеры выравнивания

Правила внесения элементов линий собраны в таблице 2, а параметры вставки форм и текста приведены в таблице 3.

Таблица 2. Внесение элементов линий

Элемент	Описание	Пример	Примечание
Штрих	Любое положительное число	10
Точка	Нулевое значение	0
Пробел	Любое отрицательное число	-10
Текст	["Текст", имя текстового стиля, параметры вставки текста]	["Нюхль",NIFFLER,S=5]	Текстовый стиль сзаданным именем обязательно должен быть создан до импорта линии. Имя шрифта, который используется в этой линии, romanc.shx
Форма	[имя формы, имя файла форм. shx, параметры вставки формы]	[COIN,COIN.shx,S=1,Y=4]	Форма с заданным именем обязательно должна быть загружена до импорта линии

Таблица 3. Параметры вставки форм и текста

Имя параметра	Описание	Пример
Масштаб	Масштабный коэффициент для формы или высоты текстового стиля. Формат записи: S=значение	S=5
Угол поворота	Угол поворота (в градусах) текста или формы относительно направления линии. Формат записи: R= значение Параметр допустимо не указывать, в этом случае его значение принимается равным 0.	R=30
Поворот текста	Этот параметр применяется при необходимости поворачивать текст или форму относительно центральной точки. Формат записи: U= значение В этом случае параметр R не записывают.	U=80
Абсолютный поворот	Угол поворота текста или формы относительно начала координат. Все текстовые объекты или все формы поворачиваются одинаково, вне зависимости от их положения относительно линии. Формат записи: А=значение Параметр допустимо не указывать, в этом случае его значение принимается равным 0.	А=-30
Смещение по X	Смещение текста или формы по оси Х, направленной вдоль линии. Формат записи: X=значение Параметр допустимо не указывать, в этом случае его значение принимается равным 0. Параметр S=значение на смещение X не влияет.	X=5
Смещение по Y	Смещение текста или формы по оси Y, направленной вдоль линии. Формат записи: Y=значение Параметр допустимо не указывать, в этом случае его значение принимается равным 0. Параметр S=значение на смещение Y не влияет.	Y=-5

Рассмотрим разницу в применении параметров R и U (рис. 14). Попробуйте самостоятельно определить, где применяется параметр R=80, а где U=80?

Рис. 14. Разница в параметрах линий

Теперь не страшно писать собственные линии, не так ли? Главное не перепутать чемоданчик для путешествий, а что в него обязательно нужно положить мы уже знаем:

переключение между разными типами линий;
загрузку новых типов линий;
создание собственных линий разными способами.

Удачного проектирования! :)

Все материалы доступны по QR-коду.

Прямая ссылка на скачивание: https://ftp.nanosoft.su/file_57689705760cb43ed6a8d4

Асель Бексултанова,
технический специалист
по Платформе nanoCAD,
Нанософт разработка
E-mail: bexultanova@nanocad.ru

Подробнее..

Категории: Инженерные системы , Cad/cam , Блог компании нанософт , Гарри поттер , Nanocad , Гост , Типы линий

Почему российские сайты не будут соответствовать ГОСТу по доступности

26.10.2020 16:12:51 |

Автор: admin

Закончив перевод Руководства по обеспечению доступности веб-контента (WCAG) 2.1 на русский язык, захотелось поговорить о языкознании, правоприменении, и поднять вынесенный в заголовок вопрос: почему российские сайты могут соответствовать WCAG, разработанным на его основе стандартам по доступности Евросоюза, США и даже Китая, но не национальному стандарту ГОСТу?

1 апреля этого года (дата выбрана весьма символичная) вступил в силу ГОСТ Р 52872-2019 Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности, заменивший ГОСТ Р 52872-2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению.

Ссылка на текст действующего ГОСТа ведет на неофициальную копию в PDF, поскольку официальная ссылка с сайта Росстандарта на текст ГОСТа по доступности ведет на не доступную версию в формате JPG, что явно возбраняется этим же ГОСТом. Л логика, но я сейчас о другом, а именно: об утверждении при разработке настоящего стандарта за основу был взят актуальный на этот момент документ Web Content Accessibility Guidelines (WCAG) 2.1, содержащемся в разделе Введение недоступного ГОСТа по доступности.

Начнем с того, что вообще такое стандарт. Грубо говоря, это 2х2=4, в километре 1000 метров, а питьевое молоко продукт нормальной физиологической секреции молочных желез сельскохозяйственных животных <> без каких-либо добавлений к этому продукту, все остальное молокосодержащий продукт.

WCAG это не стандарт, а рекомендация (именно такой официальный статус носит этот документ): хорошо, если в вашем километре будет не менее 900 и не более 1100 метров, еще лучше, если 950-1050, а в идеале ровно 1000, но идеал не всегда достижим. Во WCAG это называется уровень соответствия, их три: А (удовлетворительно), АА (хорошо) и ААА (отлично). Внимание, вопрос: соответствие какому из этих трех уровней рекомендации является соответствием стандарту ГОСТу? Об этом никто из авторов не подумал.

Теперь почитаем WCAG, прямо с первого абзаца: следование Руководству сделает контент более доступным для большего числа людей с различными ограничениями. В то же время название ГОСТа: Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Хотя во WCAG прямо говорится: Веб-доступность зависит не только от доступности контента, но и поддержки функций доступности со стороны веб-браузеров и других агентов пользователя. Средства создания контента также играют важную роль в обеспечении веб-доступности. См. обзорные материалы по вопросам совместного функционирования этих компонентов веб-разработки и взаимодействия и даются отсылки к профильным нормативам по обеспечению доступности интерфейсов UAAG и ATAG.

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

Теперь самое веселое перевод WCAG, который стал ГОСТом, то есть государственным стандартом, на секундочку. Например, п.3.1.2 ГОСТа дает такое определение термина активный указатель: устройство ввода, которое может быть направлено на конкретную точку (точки) на экране, такое как мышь, стилус или палец пользователя.

Оригинал этого определения на английском языке: pointer input input device that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.

Отталкиваясь лишь от одного из значений английского слова device устройство, прибор переводчик отнес к ним и человеческий палец, тогда как в оригинале имелось в виду другое значение этого слова способ, метод. Таким образом, в исходном тексте (и по контексту WCAG это совершенно очевидно) имелся в виду метод, способ ввода информации, а не устройство ввода. При этом остается неясным, почему в переводе указатель стал активным и чем обусловлена эта отсебятина.

Упомянутое определение можно было перевести на русский язык, например, следующим образом: ввод указателем ввод данных или команд путем указания определенных координат на экране, например, с помощью мыши, стилуса или прикосновения.

Другим примером ошибочного перевода служит перевод термина alternative for time-based media, названного в п.3.1.4 ГОСТ альтернативным представлением медиаконтента, ограниченного по времени, и сделанный следующим образом: правильно составленный текстовый комментарий, содержащийся в контенте, синхронизированный с ограниченной по времени видео- или аудиоинформацией и предоставляющий возможность ее интерактивного использования.
Примечание: Программный сценарий (скрипт), используемый для создания синхронизированного медиаконтента, может соответствовать этому определению, если он был скорректирован для точного представления синхронизируемого медиаконтенга после его публикации.

WCAG дает следующее определение этому термину на английском языке: document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction
Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing.

В данном случае ~~неверно переведен целый ряд терминов~~ переврано абсолютно все:

time-based media это не медиаконтент, ограниченный по времени, а динамичный медиа-контент, представляемый пользователю не одномоментно, а последовательно, например, аудиовизуальный файл (фильм);
correctly sequenced text descriptions это не правильно составленный текстовый комментарий <...> синхронизированный с ограниченной по времени видео- или аудиоинформацией, а текстовое описание в правильной последовательности динамичной визуальной и звуковой информации. Другими словами, это способ предоставить пользователю с ограничениями по зрению или слуху текстовую версию информации, содержащейся в видео- или звуковом формате. При этом во WCAG не указывается, что текстовая альтернатива должна быть синхронизирована с оригинальным медиафайлом, это отсебятина авторов ГОСТа, уточняется лишь, что она должна предоставлять информацию в том же порядке;
providing a means for achieving the outcomes of any time-based interaction это не предоставляющий возможность ее интерактивного использования, а предоставляющий средства достижения [того же] результата взаимодействия с динамичным контентом. Например, текстовая альтернатива интерактивному меню (созданному, скажем, на Flash) должна обеспечить ту же возможность пользоваться навигацией по сайту, что и само интерактивное меню;
screenplay это не программный сценарий (скрипт), а обычный сценарий, используемый при постановках в театре, кино, на телевидении и т.п. Во WCAG говорится, что текстовой сценарий, например, фильма может использоваться как текстовая альтернатива динамичному медиа-контенту аудиовизуальному файлу с фильмом, но лишь в том случае, если сценарий точно соответствует итоговому произведению, а не является черновиком, в который при съемках или монтаже были внесены изменения.

Таким образом, определение термина alternative for time-based media на русском языке могло бы звучать следующим образом:
альтернатива динамичному медиа-контенту (alternative for time-based media) документ, включающий текстовое описание в правильной последовательности динамичной визуальной и звуковой информации, и предоставляющий средства достижения результата взаимодействия с динамичным контентом.
Прим: сценарий, использованный для создания синхронизированного медиа-контента, будет соответствовать этому определению, если он будет отредактирован для точного представления полученного в результате медиа-контента.

Это лишь два примера с первой же страницы ГОСТа, а подобного рода грубые ошибки, отсебятина и неточности перевода встречаются буквально в каждом его абзаце.

Тут мне могут возразить, что ~~колхоз~~ ГОСТ дело добровольное, применять его или нет решает владелец сайта. Но давайте послушаем мнение органов прокуратуры и судов.

Сыктывкарский городской суд Республики Коми <> рассмотрев в открытом судебном заседании гражданское дело по исковому заявлению Сыктывкарского транспортного прокурора в интересах неопределенного круга лиц к АО Комиавиатранс о приведении интернет-ресурса в соответствие с требованиями законодательства о социальной защите инвалидов, установил: <> вывод об отсутствие дискриминации по признаку инвалидности при использовании интернет-ресурса может быть сделан лишь при соответствии сайтов ГОСТ Р 52872-2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению <> решил: признать незаконным бездействие и обязать АО Комиавиатранс привести сайт в соответствие с требованиями, установленными ГОСТом Р 52872-2012 Интернет ресурсы. Требования доступности для инвалидов по зрению.

Думаете, это единичный случай? Нет, были и другие решения, по всей стране: Волгоградская область, Тверская область, Москва, далее везде. Пока мне попадались только дела, связанные с предыдущей редакцией ГОСТа, но сути это не меняет: надзор и суд считают ГОСТ в области доступности сайтов обязательным к применению.

С учетом этого владельцы сайтов оказываются перед вилами: ~~просто забить на доступность~~ обеспечить соответствие своих сайтов единому международному нормативу WCAG, либо безграмотному и многократно перевранному ГОСТу. В первом случае торжествует здравый смысл и обеспечивается реальная доступность сайта для инвалидов, во втором торжествует маразм и формализм, зато отсутствует повод для претензий со стороны органов прокуратуры и судебной системы.

Какой вариант соответствия выберут владельцы сайтов? Я надеюсь тот, который общепринят, для которого существуют многочисленные средства валидации, который поддерживается всеми современными средствами веб-разработки, агентами пользователя и ассистивными технологиями, а не тот, который несколько безграмотных, но амбициозных авторов при попустительстве Росстандарта решили сделать ГОСТом. Но, как уже было сказано выше, есть нюанс

Подробнее..

Категории: Перевод , Разработка веб-сайтов , Accessibility , Доступность , Wcag , Гост

На пути к вершине Магма и Кузнечик на Эльбрусе

17.06.2021 16:13:58 |

Автор: admin

В последнее время всё чаще появляются статьи о производительности российских процессоров Эльбрус на различных задачах. Тема криптографии пока что остаётся за кадром, хотя в разное время были упоминания то о высоких возможностях Эльбруса (некий ГОСТ лучше в 9 раз на Эльбрус-4С, чем на Intel Core i7-2600), то о плохой оптимизации компилятора и, соответственно, крайне низкой скорости реализованных алгоритмов (Кузнечик в 100 раз медленнее, чем на Intel?). Предлагаю наконец разобраться, что может Эльбрус, на примере двух ГОСТ алгоритмов симметричного шифрования.

Чтобы статья не вышла слишком большой, будем считать, что читатель имеет общее представление об архитектурах процессоров, в том числе знает об Эльбрусе. Если же нет, на сайте разработчика (компании МЦСТ) есть отличное руководство по программированию и книга об архитектуре в целом. Именно с этих материалов и началось моё знакомство с Эльбрусами. Также отмечу, что в современных процессорах очень много различных механизмов и особенностей, так что в статье буду касаться только тех, которые, на мой взгляд, важны при реализации выбранных алгоритмов.

Что может предложить архитектура Эльбрус

Для выполнения арифметических операций у Эльбруса есть 6 АЛУ (арифметико-логических устройств), способных выполнять операции параллельно. Начиная с версии 5 архитектуры появилась поддержка упакованных (SIMD) инструкций над 128-битными регистрами.

Для хранения промежуточных результатов присутствует большой регистровый файл: суммарно в процедуре можно использовать более 200 (64-битных) регистров общего назначения. Для SIMD вычислений используются те же самые регистры, а не отдельные, как это часто бывает. Соответственно, с 5 версии архитектуры все регистры стали 128-битными.

Задачу симметричного шифрования можно отнести к потоковой обработке массива данных. Для таких ситуаций в Эльбрусе есть механизм асинхронной подкачки данных из памяти APB (Array Prefetch Buffer). Использование этого механизма позволяет вовремя подгружать данные из памяти, не теряя время на кэш-промахи.

Выбор реализаций

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

Правда, о производительности ГОСТ алгоритмов обычно говорят только в контексте семейства x86-64, другие архитектуры мало кого интересуют. Но это не беда: мне показалось, что при знании команд ассемблера x86-64 ознакомиться с набором целочисленных и логических инструкций Эльбруса проще, чем, скажем, с ARM-овым. То есть прослеживаются определённые параллели, особенно, в области SIMD инструкций, и даже прямые аналоги. В остальном, конечно, у них нет ничего общего.

Итак, для Магмы известна эффективная реализация режимов, допускающих параллельную обработку блоков, то есть когда несколько блоков могут шифроваться независимо друг от друга. Это, например, режимы ECB, CTR, MGM. При этом скорость конкурирует с AES, для которого на x86-64 есть аппаратная поддержка. Реализация заточена именно под параллельную обработку, в случае последовательной (режимы с зацеплением) используются другие подходы. Мне интересно добиться максимальной скорости, поэтому я ограничился только случаем параллельной обработки.

С Кузнечиком немного проще: лучшие результаты что при последовательной, что при параллельной обработке даёт одна и та же реализация её и берём.

Тестовые машины

То же самое в текстовом виде

Процессор	Версия арх-ры	Кол-во ядер	Тактовая частота	L1d	L1i	L2	L3
Эльбрус-4С	E2Kv3	4	0.75 ГГц	4 x 64 КБ	4 x 128 КБ	4 x 2 МБ	Нет
Эльбрус-1С+	E2Kv4	1	0.985 ГГц	1 x 64 КБ	1 x 128 КБ	1 x 2 МБ	Нет
Эльбрус-8С	E2Kv4	8	1.2 ГГц	8 x 64 КБ	8 x 128 КБ	8 x 512 КБ	16 МБ
Эльбрус-8СВ	E2Kv5	8	1.55 ГГц	8 x 64 КБ	8 x 128 КБ	8 x 512 КБ	16 МБ
Эльбрус-2С3	E2Kv6	2	2 ГГц	2 x 64 КБ	2 x 128 КБ	2 x 2 МБ	Нет
Эльбрус-16С	E2Kv6	16	2 ГГц	16 x 64 КБ	16 x 128 КБ	8 x 1 МБ	32 МБ

Магма

В случае x86-64 быстрая реализация Магмы опирается на использование расширений AVX и AVX2. При этом учитывается наличие в процессоре нескольких АЛУ и возможность параллельного исполнения до 3 векторных инструкций за один такт. Естественно, планирование параллельного исполнения остаётся на откуп процессора.

В случае же Эльбруса есть возможность явно распланировать параллельное исполнение. Опуская некоторые детали, можно считать, что на 3 и 4 поколении возможно исполнить 6 целочисленных векторных операций над 64-битными регистрами, а начиная с 5 поколения 4 векторных операции уже над 128-битными регистрами.

Для Эльбруса я написал собственную реализацию Магмы. Она использует те же идеи, что и исходная под x86-64, но при этом адаптирована под другой набор инструкций. Рассматривал перспективу написания на ассемблере и даже пробовал, но довольно быстро осознал, что ассемблер у Эльбруса достаточно сложный в плане программирования на нём (например, есть много нюансов по размерам задержек и зависимостям инструкций, которые тяжело учесть вручную). При этом оптимизирующий компилятор делает свою работу действительно хорошо: переставляет инструкции в рамках большого окна и при подборе опций компиляции выдаёт плотность кода, которая не отличается от теоретических оценок на количество инструкций и тактов. Так что я остановился на реализации на языке Си с использованием intrinsic функций для доступа к некоторым инструкциям процессора.

Для измерения скорости был выбран режим ECB. Обычно именно он (или даже его упрощения) используется при сравнении производительности, а скорость других режимов можно оценить на базе полученных результатов, отличия несущественны. Речь идёт о реализации базового алгоритма шифрования, поэтому накладные расходы от смены ключа также не учитываются. Объём данных для замера порядка 1 ГБ. Естественно, шифрование на одном ядре. Для многоядерной машины можно умножить результат на количество ядер и получить близкую к реальности оценку скорости. По крайней мере, во всех сравнениях я видел именно такую зависимость. Полученные результаты в таблице ниже:

То же самое в текстовом виде

Процессор	Скорость на невыровненных данных	Скорость на выровненных данных	Производительность
Эльбрус-4С	116 МБ/с	137 МБ/с	5.2 такт/байт
Эльбрус-1С+	151 МБ/с	179 МБ/с	5.2 такт/байт
Эльбрус-8С	185 МБ/с	220 МБ/с	5.2 такт/байт
Эльбрус-8СВ	402 МБ/с	520 МБ/с	2.8 такт/байт
Эльбрус-2С3	669 МБ/с	670 МБ/с	2.8 такт/байт
Эльбрус-16С	671 МБ/с	672 МБ/с	2.8 такт/байт

Здесь под выровненными данными подразумевается выравнивание по границе 8 байтов для E2Kv3/E2Kv4 и 16 байтов для E2Kv5/E2Kv6. При наличии такого выравнивания (на версиях до 6) работает механизм APB и данные для шифрования эффективно подкачиваются из памяти. При этом с версии 6 APB уже не требует выравнивания данных, поэтому при любом расположении данных достигается максимальная скорость. Для невыровненных данных на предыдущих версиях архитектуры я не провёл достаточно исследований, так что значения в этом столбце таблицы можно считать нижней границей.

Для сравнения приведу результаты из статьи с описанием базовой реализации на Intel Core i3-7100 @ 3.9 ГГц. При использовании AVX 458 МБ/с, 8.1 такт/байт; AVX2 1030 МБ/с, 3.6 такт/байт. Так что по абсолютной скорости Эльбрус достаточно близок к современным процессорам Intel (это при значительной разнице в тактовой частоте!) и превосходит x86-64 с AVX в тактах более чем в 1.5 раза (для 3 и 4 поколения), а x86-64 с AVX2 в 1.3 раза (для 5 поколения).

Кузнечик

По сравнению с Магмой, структура Кузнечика является более сложной. Несмотря на то, что удалось декомпозировать нелинейное преобразование S, техники реализации, основанные на широком использовании SIMD-инструкций, пока что отстают от "классической" реализации со склеенным LS (линейным и нелинейным) преобразованием и таблицей предвычислений размером 64 КБ (упоминается в статье под именами с LS или более простое описание на Хабре).

В случае x86-64 Кузнечик эффективнее всего реализуется с использованием AVX-инструкций (удобно работать со 128-битными регистрами, так как длина блока и размер значений в таблице равны в точности 128 битам). При этом для вычислений адресов в таблице не удаётся воспользоваться эффективной адресацией Scale-Index-Base-Displacement (именование из статьи), так как в качестве Scale нужно значение 16, а максимально возможное 8. На Эльбрусе можно ожидать конкурирующих результатов за счёт большого кэша L1d (64 КБ) и наличия 4 АЛУ, обеспечивающих произвольный доступ к памяти (насколько мне известно, у абсолютного большинства процессоров x86-64 2 порта для загрузки данных).

Как и в случае с Магмой, для Кузнечика я написал отдельную реализацию на Си под Эльбрус, чтобы добиться максимальных результатов. Начиная с 5 версии архитектуры я явным образом использовал тип __v2di (см. e2kintrin.h в составе компилятора), чтобы быть уверенным, что получится использовать регистры как 128-битные.

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

Итак, в случае строго последовательной обработки данных:

То же самое в текстовом виде

Процессор	Скорость на невыровненных данных	Скорость на выровненных данных	Производительность
Эльбрус-4С	52 МБ/с	69 МБ/с	10.4 такт/байт
Эльбрус-1С+	63 МБ/с	90 МБ/с	10.4 такт/байт
Эльбрус-8С	80 МБ/с	110 МБ/с	10.4 такт/байт
Эльбрус-8СВ	95 МБ/с	150 МБ/с	9.9 такт/байт
Эльбрус-2С3	170 МБ/с	171 МБ/с	11 такт/байт
Эльбрус-16С	171 МБ/с	172 МБ/с	11 такт/байт

Для сравнения результаты из статьи (лучшие из опубликованных) на Intel Core i7-6700 @ 4 ГГц 170МБ/с, 22.4 такт/байт. В отличие от Магмы, можно говорить о сопоставимой абсолютной скорости и преимуществе в тактах более чем в 2 раза.

В таблице заметен интересный момент: результаты ощутимо колеблются среди последних 3 версий Эльбруса. Такое поведение я заметил буквально недавно и начал обсуждение с коллегами из МЦСТ, так что есть надежда, что результаты удастся немного улучшить при доработке компилятора.

С параллельной обработкой ситуация намного интереснее:

То же самое в текстовом виде

Процессор	Скорость на невыровненных данных	Скорость на выровненных данных	Производительность
Эльбрус-4С	78 МБ/с	83 МБ/с	8.6 такт/байт
Эльбрус-1С+	102 МБ/с	108 МБ/с	8.7 такт/байт
Эльбрус-8С	126 МБ/с	133 МБ/с	8.6 такт/байт
Эльбрус-8СВ	248 МБ/с	291 МБ/с	5.1 такт/байт
Эльбрус-2С3	453 МБ/с	454 МБ/с	4.2 такт/байт
Эльбрус-16С	454 МБ/с	455 МБ/с	4.2 такт/байт

И традиционное сравнение с Intel Core i7-6700 @ 4 ГГц: на нём достигается 360 МБ/с, 10.6 такт/байт. В отличие от случая последовательной обработки, у E2Kv3 и E2Kv4 преимущество Эльбруса не такое большое, предположительно из-за того, что реализация обработки нескольких блоков вместе обладает более высокой степенью параллельности и планировщику на x86-64 легче справиться с выявлением независимых операций. А вот появление у 5 поколения Эльбруса 128-битных регистров и загрузок из памяти позволяет ему сохранить преимущество в тактах более чем в 2 раза.

Сравнивать E2Kv6 с i7-6700 оказалось несолидно, поэтому я взял ассемблерную реализацию режима ECB и провёл собственный замер. В статье с описанием результатов на i7-6700 данные шифруются на месте, без работы с памятью, поэтому у честного режима ECB результат чуточку хуже: на самом мощном из доступных мне процессоров Intel Core i7-9700K @ 4.7 ГГц вышло 411 МБ/с, 10.9 такт/байт. Эльбрус оказался быстрее, обеспечивая преимущество в тактах в 2.5 раза.

Заключение

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

За время изучения архитектуры Эльбруса у меня сложилось впечатление, что многие полезные инструкции исторически добавлялись для обеспечения работы двоичного транслятора, но ситуация изменилась с 5 версии: Эльбрус начал больше развиваться собственным путём. Эту положительную динамику невозможно не отметить.

С другой стороны, сложившаяся похожесть ряда инструкций упрощает разработку и оптимизацию под Эльбрус. Можно сказать, что эта статья предлагает простой способ портирования и оптимизации алгоритмов под Эльбрус: достаточно взять хорошо зарекомендовавший себя на Intel/AMD алгоритм и немного адаптировать его под Эльбрус. Я искренне верю, что в результате практически любой алгоритм должен работать по крайней мере не хуже, чем в разницу тактовых частот.

Если немного поразбираться и осторожно писать код на Си, компилятор прекрасно справляется с задачей оптимизации и не оставляет человеку шансов написать на ассемблере более эффективный код.

P.S.

Эта статья написана по мотивам моего устного доклада на конференции РусКрипто. По ссылке можно найти презентацию, которая является краткой выжимкой с основными результатами на тот момент. К моменту же написания статьи удалось улучшить некоторые результаты, а также проверить реализации на новом поколении процессоров.

Несмотря на то, что для получения описанных результатов мне удалось разобраться с Эльбрусом на основании только открытой информации и документации к компилятору, я хочу выразить благодарность сотрудникам МЦСТ, в особенности, Александру Трушу, за ответы на периодически возникавшие у меня вопросы и, конечно, за предоставление удалённого доступа к новым процессорам.

Подробнее..

Категории: Высокая производительность , Оптимизация , Процессоры , Криптография , Симметричное шифрование , Криптопро , Эльбрус , E2k , Мцст , Гост , Кузнечик , Магма , Блочный шифр

	Русский
	English

Гост

Шифруем по-русски, или отечественные криптоалгоритмы

Из новостей

Направления ГОСТов

Цифровая подпись

Хеш-функция

Шифры

Режимы работы шифров

Интерес к таблице подстановок

Заключение

Типы линий и где они хранятся

Почему российские сайты не будут соответствовать ГОСТу по доступности

На пути к вершине Магма и Кузнечик на Эльбрусе

Что может предложить архитектура Эльбрус

Выбор реализаций

Тестовые машины

Магма

Кузнечик

Заключение

P.S.

Категории

Последние комментарии