Реализация существенно оптимизированного алгоритма симметричного шифрования AES (Advanced Encryption Standard) в режиме ECB (Electronic codebook) с различной длиной ключа 128/192/256 без использования внешних компонент, zip-файлов, обращения к диску или БД и без привязки к ОС.
Плюс за развите темы криптографии на синтаксисе 1С.
Если можете опубликовать на github, то будет отлично, в идеале организовать библиотеку по аналогии с crypto-js в npm. Если нужны sm без проблем скачаю.
Сам для JWT использую HMAC и RSA256, первый в паблике есть, второй только в обработке на IS.
(1) Спасибо за Ваш отзыв.
Пост появился именно для того, чтобы нажить неисчислимые богатства (и больше не работать, шутка). На самом деле периодически бывает интересно что-то скачать, а местной валюты нет.
В данном случае вообще интересно получилось, так как эта статья состоялась благодаря вот этой:
https://infostart.ru/public/952753/ Мой коллега скачал обработку для меня за свои sm.
По поводу JWT - у меня та же самая задача. Ради этого и занялся. HMAC и RSA256 - это очень хорошо, и есть готовый инструмент через МенеджерКриптографии. И не надо велосипед изобретать. Но мне как-то накладно показалось в дальнейшем обслуживании. Я имею ввиду возню с сертификатами. Поэтому я начал искать симметричный алгоритм с одним закрытым ключом.
Впрочем я об этом вчера написал статью, она ещё на модерации:
https://infostart.ru/public/1319502/
В чем смысл переписывания алгоритма шифрования с плюсов на 1С? Прирост производительности мы вряд ли получим, придется много кода писать вручную. На плюсах сдвиг битов, XOR, сложение по модулю 2^32 и много чего еще, используемое в шифровании делается одной командой.
Или речь только про то, чтобы отказаться от внешних компонент?
(3) Вкратце ответ - да.
Я с Вами полностью согласен. Тратить своё время, вместо того, чтобы использовать готовое - крайне сомнительная вещь.
Однако, с другой стороны, я тут недавно переезжал большой системой с Windows на Linux, и внешние компоненты доставили, мягко говоря, хлопот.
И я пока вздрагиваю, когда читаю про внешние компоненты. Уверен это временно и скоро снова начну их применять.
Также согласен с тем, что чтобы обогнать плюсы, надо использовать не 1С, а, скажем CUDA (https://ru.wikipedia.org/wiki/CUDA). Но тут речь не про обогнать плюсы, а про приемлемое использование в 1С.
На специальном упрощённом диалекте языков C, C++, Фортран... Для успешной трансляции кода на этом языке в состав CUDA SDK входит собственный Си-компилятор командной строки nvcc компании Nvidia.
Нативный язык изначально не имеет возможностей, предоставляемых CUDA, поэтому я допустил их сравнение друг с другом.
Любое изобретение и разработка может быть использовано в разных целях. Наличие быстрого алгоритма шифрования, реализованного на 1С позволит злоумышленникам написать обработки шифрования работающие внутри платформы. Предлагаю удалить эту обработку из открытого доступа сайта Инфостарт.
(0) Спасибо за публикацию. Алгоритм Deflate/Inflate осилите? Я на днях почитал много про него, реализация на 1С должна быть крайне увлекательной несмотря на кажущуюся простоту и доступность информации.
(6) Я не про это, а про реализацию LZ77 + деревьев Хаффмана, с каноническим построением деревьев, их хранение в потоке, их восстановление, использование при декодировании и т.д.
(8) Если я правильно понимаю, хранилище значения для сжатия как раз Deflate использует. Ну то есть это уже есть на уровне платформы. Я просто не вижу сценария, при котором потребуется своя самодельная обработка.
(11) Те примеры, что вы привели относятся к разряду собственного формата входящих данных, т.к. само по себе ХранилищеЗначения сериалузется вместе с deflate потоком. Но если взять deflate данные из внешнего потока (без заголовков типа zip, gzip), то вы ничего не сможете раскодировать, т.к. внешние системы ничего не знают о типе данных ХранилищеЗначения и о том, что Deflate поток надо для нужд 1С предварять заголовком из ХЗ.
(12) Получается - да. Для связи с внешними системами нужно что-то мудрить. Потому что 1С сначала пишет данные в своём формате, а затем пакует.
P.S.: В примере вызывает подозрение два "<wbr>".
Если 2 раза откинуть <wbr>, которые добавлены механизмом расцветки ИС, то получим:
Инженер по разработке и эксплуатации информационных систем на платформе 1С:Предприятие
(23) Но это же тоже не то. Вы просто обрезаете/добавляете заголовки и используете zip. В Вашей публикации есть ремарка:
Как оказалось, на ИС уже есть похожие публикации, но там либо применяется внешний EXE-шник, либо внешняя компонента, либо работа с бинарными данными идет через европу.
Меня заинтересовал момент про "европу". Неужели кто-то на 1С уже реализовал работу с Deflate через работу с двоичными данными (алгоритмы LZ77 (через функцию кольцевого-хэша по примеру Рабина-Карпа, как в Zlib), кодирование Хаффмана)?
(24) Прямого алгоритма "в лоб" на 1с не встречал. Да и если таковой и появится, то он будет очень уныло работать, т. к. эска не предназначена для алгоритмических задач. А в кодировании Хаффмана там вообще используются биты...
(4)А если это произойдёт во вторник - давайте запретим вторники.
"Предлагаю удалить эту обработку из открытого доступа сайта Инфостарт." спасибо, поржал.
"МенеджерКриптографии" - у меня не взлетело на PEM формате, RS256 использую для гугл, HS256 для пары сервисов.
"Впрочем я об этом вчера написал статью" - поддержал плюсом и скачиванием, не увидел как подготовить ключ для использования, Google выдает p12 или PEM обернутый в JSON, проблема распаковки описана в комментариях к статье https://infostart.ru/public/805071/
Либо подаёте произвольные ДвоичныеДанные длиной 32 байта, либо можно SHA-256 получить от произвольной строки - пароля. В примере использован второй вариант.
По поводу остального - спасибо за информацию. Изучаю.
(3) "Или речь только про то, чтобы отказаться от внешних компонент?" - именно так, к linux не факт что компоненты есть, при использовании в HTTP сервисе может просадку по производительности давать.
(10) "Поэтому я начал искать симметричный алгоритм с одним закрытым ключом." - если про универсальность, то HS256 используется в https://infostart.ru/public/709325/ (https://github.com/vbondarevsky/Connector) как "AWS4-HMAC-SHA256 аутентификация".
По теме нативной реализации, в одном из API столкнулся с "PKCS 1", который для Java программистов "включил и работает", нас стороне 1С не смог запустить, решили изменением формата.
Здравствуйте. Я параноик и социопат, а по этому задам вам тот же вопрос что и Никите по поводу его разработки - можно ли вашей обработкой шифровать реально серьезные вещи, пинкоды карт в базе, пароли от почты и пр.?
P.S. Обработку уже купил, она действительно быстрая. Кстати с Никитиной обработкой прикол был - на компе у меня медленней в шифровалось и дешифровалось чем на смартфоне под Андроидом.
Я параноик и социопат, а по этому задам вам тот же вопрос что и Никите по поводу его разработки - можно ли вашей обработкой шифровать реально серьезные вещи, пинкоды карт в базе, пароли от почты и пр.?
Кратко - да.
Подробности:
Я гарантирую, что код модуля обработки в точности выполняет алгоритм AES. Это можно быстро проверить, зашифровав что-нибудь обработкой, а расшифровать сторонней программой. Можете вот на этом сайте попробовать - он поддерживает HEX-ключи. Либо выберите любой другой сайт.
По поводу надёжности самого алгоритма - вам стоит обратиться к его авторам. Но вообще считается, что это наиболее безопасный алгоритм шифрования среди симметричных алгоритмов. 26 ноября 2001 года AES был принят как федеральный стандарт (правительство США) обработки информации FIPS 197.
Также следует учесть, что данная обработка - это всего лишь инструмент. Многое зависит от того, как его применять. Например, в обработке (в форме) для наглядности используется пароль в виде фразы, который преобразуется в ключ путём получения хэша SHA-256. Это делает доступным перебор по словарю. Намного лучше, если ключ будет набором случайных байт (длинной 32 байта, разумеется).
Однозначно плюс. Была бы возможность, поставил бы два плюса.
Для обмена с мобильной платформой просто шикарная вещь. Ибо возиться с сертификатами на адроиде это тот еще мазохизм. Кидать не зашифрованные пакеты по открытым каналам не айс. А так можно шифровать без всяких лишних проблем и багов.
Отлично оформлен программный код. Из названий процедур и функций понятно, что в них обрабатывается.
Даже недочетов то никаких не нашел. Ну разве уж совсем мелкие. Как то:
Дополнение исходного сообщение до нужной длины нулями. Если исходное сообщение заканчивается нулями, (а если шифруется не текст, а произвольные данные, то это вполне возможно) то при расшифровке конец исходного сообщения отрежется. К тому же, такой вариант приводит к атакам Оракула дополнения.
(35) Спасибо за отзыв. Очень приятно, что оценили оформление.
На счёт нулей - тут уж пардоньте - по стандарту дополняется нулями. Я от себя ничего не добавлял/убавлял.
С другой стороны при желании несложно же дополнить чем то другим.
Абсолютно согласен. Собственно это была не претензия, это было мнение. Вообще есть разные стандарты дополнения, но это не суть важно. Работа проделана огромная, остальное поправить при необходимости не представляет особого труда. Еще раз респект.