В случае эльгамаля сжатие не дается бесплатно — он существенно упрощает перебор, причем быстрее, чем сокращает подпись — если подпись короче в два раза, то перебор быстрее в четыре. Эльгамаль длиной 80 бит, кстати, требует всего 2^40 операций подбора, не 2^80. Причем валидация подписи существенно сложнее, чем перебор, так как для перебора (для начала) нам необходимо восстановить k по известному r, не трогая никак s. А оно простое для вычисления, без длинной арифметики даже (хотя нет, mod придется эмулировать). Т.е. трюк «проверяем секунду, зато подбираем вечность» — может быть неприменим.
q тоже берется не с потолка, оно должно быть делителем p — 1. А если оно им не будет, то работать совсем перестанет. Нельзя просто так взять и что-то поменять — обернуть в поверхность или функцию, необходимы
Я понимаю ваш посыл, что вы предлагаете как-то в процессе манипуляций с сообщением или промежуточным результатом уйти в меньшую размерность, но как — в упор не вижу. Пока мне кажется, что все навешанные сложности можно будет эффективно закешировать, сведя их эффект на нет, но это моё видение подхода, у вас оно может как-то отличаться.
Ну и отдельный вопрос. Я тут говорил про отрезание младших бит, вы вроде сказали, что это не то, а потом показываете пример с делением, которых по сути то же самое, только биты с другой стороны. Ну и перемешивание легкое, но это вроде несущественно. Это сбой аналогии или мы друг друга не понимаем?
Да нет, я понимаю, что непрерывные функции восстановимы, я, похоже, не понимаю, к чему она тут вообще. Мы сжимаем цифровую подпись, она на множестве дискретных чисел. При чем здесь функция от действительных? Для их хранения потребуются биты на дробную часть. Что-то я тут упускаю.
Давайте так. Любая известная подпись — это функция на группе. Шифровать до или после бессмысленно — Ева сделает шифровку текста или дешифровку подписи и пойдет брутфорсить. Вставить шифровку (преобразование) внутрь функции подписи нельзя — шифротекст может вылететь из нашей группы, дальше группа его обрежет и восстановить его (проверить подпись) будет сложно. Но это вопрос открытый, допускаю, что может быть такое преобразование. Но это точно не AES-о подобное.
Энтропия подписи максимальна — сжимать её обратимо что сжимать zip архив. Сжимать её необратимо можно, но тогда проверяющей стороне потребуется выполнить проверку множества потенциальных подписей (результат обращения многозначен). Это примерно похоже на ваш метод, но удвоение сложности подбора удваивает стоимость проверки. Надо отдельно оценивать, сейчас я уже не в состоянии.
Я никак не могу найти подпись в ECIES — оно вроде как Encryption Scheme. Я видел в одном RFC что-то про аутентификацию, но оно отличалось от шифрования константой, а не алгоритмом. Покажите, пожалуйста, куда конкретно смотреть. Ну или напишите пару формул, вряд ли там что-то более сложное.
Т.е. распределение тут — более менее равномерное.
А то, что вы назвали коллизиями — есть просто функция дискретного пере-распределения по X.
Мощность множества по оси X здесь — 350. Мощность множества по оси Y — 10^7. От пределов min/max их соотношение зависит практически никак. Как вы шифрованием переходите от одного к другому? Хешем — понятно, но шифрованием? Это же не функция на множестве действительных чисел, у нас дискретный случай.
На ум приходит только вариант с отрезанием младших бит, но он добавляет совсем немного сложности.
Про Elgamal мне известно. Почему вы не продолжили и не написали, то q минимум 160? Я могу продолжить и сказать, что пара подписи (x,y) эллиптической кривой можно сократить до (x, bool), т.к. одному x соответствует максимум два y. А вот то, что можно это безболезненно уполовинить — это для криптографов, действительно, новость.
Мне нравится ваш переход к математике. Давайте
r = g ^ k (mod p)
s = ( H(m) — xr ) k^(-1) (mod p — 1)
H — хеш для данных
m — ваш билет
x — приватных ключ
k — случайное число. Остальное очевидно.
Куда вы тут шифр вставите? Как будете верифицировать подпись?
Про график. Если его нарисовать не в логарифмическом масштабе, а как есть, а потом вспомнить, что мы работаем над полем целых чисел, то одному x будет соответствовать несколько y. Это гарантирует коллизии и уменьшает оценку 2^80 для перебора. Только падение сложности от коллизий будет экспоненциальным, а усложнение от симметричного шифра — линейным.
В любом случае какой-либо симметричный алгоритм (шифратор или другой) такого не позволяет, ведь тогда он перестанет быть симметричным.
Вы знаете, с самого начала мне было понятно, что мой оппонент предлагает какие-то невозможные вещи, типа полиномиального решения задачи о рюкзаке. Вот вы бы стали с подсказками такое решать? И я не стал. В итоге товарищ выкатил псевдополиномиальный алгоритм и в принципе не может понять, что здесь не так.
Вы можете прочитать нашу переписку и рассудить, кто прав, а кто нет?
P.S. Да, на решение этой задачки я потратил несколько лет :)
Да нет, я предлагаю пойти дальше. Смотрите, данные «турникета» абсолютно безопасны к распространению. Т.е. мы можем их опубликовать и получить «публичный ключ». А всё, что сейчас знает «кассир» назовем «приватным ключом». Схема оффлайновая, поэтому никаких других обменов не надо. И это будет работать в любых приложениях, хоть HTTPS подписывать, хоть код, хоть договора на миллионы долларов, ведь хакерам придется 3.8e+11 CPU-лет (но я посчитал, что даже GPU, т.е. еще круче) потратить для взлома жалких 80 бит. Certicom ECC challenge над полем ~2^97 взломали перебором за жалкие 53 дня группой из 1288 компьютеров в далеком 1998 году, а ваша подпись устоит 1^11 лет на самом современном оборудовании!
Я прозрачно подвожу вас к заключению, что вы создали офигительно крутую схему. Настолько же крутую, как вечный двигатель для физиков. И вас, похоже, ничего не смущает.
> Не важно что они у них появятся — главное что у них нет ECpriv.
Т. е. создать подпись они не могут. Еще раз без перебора подписи, тупо проверяя их прогоном через всё остальное (известные ECpub, AES ключи/алгоритм построения), подписать собственноручно созданный билет ВСЕ РАВНО не получится. Только перебор.
Они возьмут билет, расшифруют его ключом AES много тысяч раз, а дальше задача свелась к подбору ECpriv на 80 битах. При этом защиты от перебора уже нет.
ЭЦП — это ЭЦП. Ничего я нигде не путаю. Если процедура проверки алгоритмом предусматривает дополнительный ключ, то это ничего не меняет в размере собственно ЭЦП. ЭЦП прикладывается к документу (билету) и проверяет тем самым его подлинность.
Про дополнительный ключ я вам уже говорил сильно выше, он во первых "оффлайновый", во вторых имеет здесь место постольку поскольку алгоритм "из коробки" (на котором вы так настаивали) его требует. Можно и без него вообще по другому.
ЭЦП нужна для того, чтобы проверяющая сторона не могла подпись подделать. В данном случае это турникет. Да, это выглядит странно, но тем не менее, с точки зрения ЭЦП стойкость тут — ECC над полем 2^80, потому как у турникета все симметричные ключи есть. У "хакеров" их, конечно нет, как нет, впрочем, и ECpub.
Другими словами, компрометация валидирующей стороны рушит схему, а в ЭЦП такого быть не должно. То есть это не ЭЦП. Это просто схема с симметричным шифрованием. Что не делает её непригодной, просто переусложненной (продолжение через два пункта).
Ну да, а элиптика (EC, которую вы кстати сюда притянули) она конечно же не ресурсоемкая!
Эллиптика ресурсоемкая (кстати, вы её тоже притянули!), но она необходима для компактности. ECDSA гарантирует (как может), что при вскрытии турникета жулик не получит ничего. Ваша схема не гарантирует.
Вы теоретик?
Я практик с хорошим физмат образованием. Шесть лет назад я работал над практически идентичной проблемой, но мой "турникет" должен был работать в среде сотрудников с низкой социальной ответственностью (нет, это не известная идиома, просто совпадение). Из специализированных форумов я знаю, что "турникеты" были разобраны и тщательно изучены, в них были найдены все "скрытые" ключи и константы. Это жуликам не помогло.
Из-за возможных авторских, патентных и прочих опасений, вся криптография была написана руками с нуля по описаниям алгоритмов, начиная с длинной арифметики. Не вся лично мной, но достаточно много. Что еще добавить? Моя дипломная работа включала создание ИС для автоматического пояска уязвимостей в криптосхемах. Но работа откровенно слабая, а эта часть была побочной, так что хвалиться тут нечем, я только иллюстрирую свою вовлеченность в проблематику.
И потом, "с меньшей" чем которая? Чем стойкость алгоритма с хэшем, посыпаным солью? Вы серьезно?!
Неточно выразился, согласен. Имелась в виду схема "раздать всем набор ключей на год" (почти как у вас), а потом просто шифровать ими сообщения. 128 бит, все под полезную информацию (против 62 у вас) — как раз целый блок хорошего шифра. Остальное (16 бит) следует отдать под чексумму открытого текста (а-ля MAC). Тут вроде честные 2^128 получаются и можно многократно не шифровать — экономия батарейки. Ладно, фигня эта батарейка, механика принтера больше съест.
Для проверки нескольких тысяч билетов в день, это все — абсолютная ерунда, даже на батарейках. Я вам говорил про средство от брута, т.е. затруднение перебора 2^80 вариантов (или 1.2e+24), что согласитесь очень далеко от 1e+5.
Да, я понял, что это средство от брута. Я, собственно согласился с вашей временной оценкой. Исходил я из того, что при выдаче билета у нас есть всего секунда на выполнение всех шифрующих итераций — никто не станет ждать билет минуту или час. Поэтому сверху есть секунда STM32 (кассир-контроллер) — снизу имеем 6,6 мкс на CUDA (хакер).
Их полно. Единственное изменение допущенное мною — не однократное, а многократное "шифрование" внутри миксапа. Что на стойкость самой схемы подписи влияет столько же, на сколь различаются к примеру однократное и пятикратное шифрование AES (т. е. никак). Оно здесь, еще раз, только для "замедления" брута.
Есть класс атак Meet-in-the-middle. Из-за них, например, double DES бессмыслен. Я не говорю, что AES им подвержен, требования к памяти тут просто взрываются, но вдруг что-то есть? Беглый поиск показал, что все предлагают делать каскадное шифрование с разными ключами, а тут ключ один, получается, проблему никто не изучал. Вдруг после n-ой итерации мы получим промежуточное значение, сильно коррелирующее с изначальным или конечным? Мы тут как-никак 12 тыс проходов делаем. Ну, кстати, вот еще идея для усложнения перебора — использовать несколько ключей.
Вот это вот куда приложить, в свете полного перебора, результата вектора проекции кривой многократно измененного симметрикой перед обратной трансформацией от паблика. Ничего там нигде не "изнашивается". Вы чего право слова?
Тоже плохо выразился. Смотрите, вы шифруете точку кривой размером 80 бит. Делаете предположение, что в ней все биты абсолютно случайны, поэтому нам потребуется полный перебор. Верно ли это?
Теорема Хассе говорит, что в кривой у нас минимум 2^80 — 2^40 точек, так что здесь я поторопился с критикой, распределение более-менее случайное. Если, конечно, не забыть точки сжать, иначе в 80 битах у нас только 2^40 точек влезет. Но это всё несущественные нюансы.
Пора подводить итог. Я бы никогда не пришел к такой схеме, какие бы очевидные подсказки вы бы мне не давали, просто потому, что для меня это очевидно не ЭЦП. Поэтому я вас в тролли и записывал. Вы сделали интересный подход с усложнением перебора, но он уходит в terra incognita, и я на такое в коммерческом проекте не решился бы. К тому же есть более простое и эффективное решение с не меньшей стойкостью.
Жалко, что для прихода к этому пришлось потратить так много времени, текста и нервов. Вроде взрослые люди, а язык общий найти не можем. А знаете, что самое смешное? В день публикации этой чебурашки я ездил на электричке. Так вот на билете там — PDF417.
Я рад, что вы слезли наконец с коня. Право, было неудобно каждый раз поднимать голову.
Вы путаетесь в базовых понятиях. ЭЦП — это механизм, позволяющий с публичным ключом проверить подпись, которую можно сделать только с приватным ключом. В вашей системе это не так.
Для проверки вашей "подписи" необходимо помимо ECpub знать еще и ключ симметричного шифрования (иначе вы ничего не проверите). Именно эта пара и является публичным ключом, а не то, что вы себе нафантазировали. Просто по определению ЭЦП. Соответственно дальше задача идет по одному из двух путей (в зависимости от вашего алгоритма):
Если ваша схема шифрует подпись симметрично, то мы её расшифровываем и далее задача свелась к подбору ключа ECC для поля 2^79. Если вы не догадались при этом применить сжатие точек — то для поля 2^40. Это вычислительно несложная задача, особенно с помощью CUDA. Тем более для целого общежития студентов. Они сделают это не для личной выгоды, а just for fun. Кстати, а что у вас за шифратор такой, чтобы 80 бит породить? Точно стойкий? :)
Если ваша схема шифрует подпись несимметрично (обрезает шифротекст до 80 бит), о чем намекают ваши фразы "вам не нужно расшифровывать" и "ключами любой длины", то для проверки необходимо, чтобы у проверяющего был ECpriv (иначе что он будет расшифровывать?). Я стараюсь воздержаться от дальнейших комментариев этой глупости, надеюсь, я просто неправильно вас понял.
Если же мы будем рассматривать взлом со стороны, то вся схема свелась к той, что я уже упоминал — симметричный шифр с заранее распространенным блокнотом паролей. Только там мы сразу взяли простое шифрование с блоком 128, т.е. та схема была более стойкой.
Суммируя — вы придумали более ресурсоемкую схему с меньшей стойкостью. Ресурсоемкость, кстати, очень важна, ведь мобильным контроллерам приходится натурально таскать с собой запасные батарейки для терминалов, а тут вы эти терминалы усиленно разряжаете. Очень некрасиво по отношению к дамам.
Обратите внимание, я намеренно не использовал нигде конкретные реализации конкретных алгоритмов, а повествовал в наиболее общем виде. Это чтобы вы опять не стали опять ёрничать, что "эта схема не единственная, а всего одна из..., и вообще у вас ECIES не той системы".
Мы спорили про "ЭЦП может быть любой длины". Вы не смогли подтвердить это своё высказывание. В том, что вы можете сделать какую-нибудь схему для билетов электричек я, собственно, не сомневался — это достаточно тривиальная задача. Если, конечно, не пытаться сделать "её полностью оффлайновой" — то, с чего начиналась ветка, в которую вы так бесцеремонно влезли.
Ну и по мелочи:
Под "необходимым" количеством повторов, понимается снижение скорости проверки подписи до приемлемой.
Например, на какой-нибудь число-дробилке — за 10 микросекунд (что соответствует средней железке ~ 250 микросекунд).
Отталкиваться следует от возможностей мобильного терминала, а не "среднего железа". Я не профессионал, но, кажется, они поголовно делаются на STM32. Я бы выделил под подпись секунду, не более. STM32 аппаратно укладывается в 2500 тактов на блок (включая инициализацию), итого 14,4 тыс блоков в секунду (на 36MHz). На Geforce 1080 можно достичь 277 Gbps = 2,16 млрд блоков в секунду. Т.е. 6,6 микросекунд на секунду STM32. Ваша оценка оказалась близка к моей — у нас есть точки совпадения мнений :)
Да, если вы определите понятие, что такое здесь "стойкость решения"
Имеется в виду хоть сколько-нибудь теоретическое исследование на тему, например, энтропии битов в точках кривой, иначе вот это утверждение:
Т.к. алгоритм неразрывный, перебор подписи под известный ECpub (и "известные" симметричный ключ key, iv, и HMAC(Hash, text)) — будет полным, т.е. даже зная все составляющие (кроме ECpriv), необходим итеративный брут всех значений, до максимально 2**80.
является голословным. Вы же помните, что на флеше контроллеров, если хранить часто инкрементируемое значение, "младшие биты" быстрее "старших" изнашиваются? Ну или другой пример, что rand() % 100 не дает равномерно распределенные точки? А вдруг тут есть схожий эффект и вся ваша схема вообще в поле 2^8 вырождается? Да-да, бремя доказательства лежит на вас.
Т.е. например, разницу между "подписать" билет стоимостью 12 рублей и "подписать" какую-нибудь транзакцию на несколько миллионов, вы не видите в принципе?
Я вам помогу немного — в одном случае рентабельность сего действа убегает в минус после уже каких-то шести кВт-часов.
Существуют билеты стоимостью более 200 рублей (например, экспрессы). В общежитии МФТИ студенты не платят за кВт*ч, имеют по индивидуальному компьютеру и часто имеют бесплатный доступ к очень мощным вычислительным кластерам. В общем, не всё так однозначно.
У вас есть возражения по существу высказанных мною тезисов?
> Короткий private обеспечивает вам короткую подпись
Это утверждение ложно. Все известные мне алгоритмы ЭЦП базируются на сложности задачи факторизации в группе (вычетов или точек эллиптической кривой). На выходе всех этих алгоритмов получаются элементы это группы. Соответственно их размер вообще никак не определяется приватным ключом, а определяется исключительно размером группы.
Вполне возможно, что у нас расхождение терминологии и под «подписью» вы подразумеваете нечто другое. Либо вы знаете какой-то неизвестный мне алгоритм.
> чем гарантирована «устойчивость» подписи? Не длинной ключей (вернее не напрямую)
Напрямую гарантируется неустойчивость, если неправильно выбрать ключ. Например, если взять его коротким (меньше N^(1/4)). Для понимания этого надо не RFC читать, а arXiv.org или хотя бы википедию.
> Нужно просто «немного» изменить алгоритм. <и далее>
А это уже просто смешно. Вы всерьез считаете себя достаточно компетентным, чтобы доказать стойкость такого решения? Или это будет алгоритм неуловимого Джо?
Давайте я резюмирую. Криптографы всей планеты пытаются создать наиболее компактные способы цифровой подписи данных, а тут врываетесь вы на коне и говорите, что «нужно просто „немного“ изменить алгоритм». Халява, что уж. «А мужики-то не знают».
Ну наконец-то стал понятен ход вашей мысли. Давайте я и вам поясню.
В ветке обсуждалось полностью оффлайновое решение проблемы. Проблема в том, что кассирам-контроллерам неудобно каждый день выполнять синхронизацию с центральным сервером. Я не знаю, почему, но вот примем такой факт. Далее demfoloro на вопрос "как сделать оффлайновый билет" отвечает "использовать ЭЦП", на что я говорю "подпись не влезет на штрихкод".
А далее со своим комментарием зачем-то влезаете вы. Во-первых, с ложным утверждением о том, что ЭЦП может быть любого размера (нет, не может — слишком короткая перестаёт быть ЭЦП и становится дурным хешем) и вообще предлагаете восьмибитный хеш. Человек со стороны может прочитать это только как "давайте добавим к сообщению короткий хеш, в нём и будет защита".
Потом идут пассажи про "хеш подписи" и ключи, которые по умолчанию сгенерируются для шифрования и подписывания, а надо не так. Последнее в общем случае неверено — все ключи ассиметричной криптографии, используемые для подписи, могут быть использованы для шифровки и наоборот. Я допускаю, что могут быть специализированные (только на один из алгоритмов) атаки на узкие подмножества ключей, но в целом ключи универсальны.
Всё стало понятно после упоминания MIKEY. Именно в RFC 3830 есть разные константы для разных типов TEK. Оказывается, вы всё это время говорили про протокол обмена ключами? Ну тогда, чтобы это было понятно остальным, необходимо об этом как-то упомянуть. Тем более, что отношения к решаемой задаче оно имеет сильно опосредованное — нам нужно вообще исключить обмен ключами, т.е. сделать его однократным. MIKEY для этого не предназначен, его ключи ДОЛЖНЫ протухать (см. RFC 3830, п. 9.2). На 144 битах штрихкода CBC режим на 128 бит использовать не удастся, придется взять ключ покороче. 32 битный ключ идеального шифратора придется менять "задолго до" 16 тыс билетов (см. там же). 64 битный протянет, конечно, сильно дольше, хотя в нём режим CBC сильно условен. Он вырождается в ECB, приходится первый блок целиком забивать белым шумом, а нам, вообще говоря, битов впритык хватает для передачи полезной информации. ECB же режим на 64 битах — это несерьезно.
Такая ситуация часто возникает, когда кто-то пытается забить гвозди микроскопом использовать протокол для мультимедиа для обмена короткими сообщениями.
Есть такое утверждение, что симметричное шифрование не следует быть использовать для аутентификации. Однако это слишком сильное требование, поэтому часто к нему добавляют "на протяжении длительного времени". Грамотные люди стараются пользоваться этим только в крайних случаях и аккуратно оценивают риски. Фраза "не умеете их готовить" мне больше напоминает сову-стратега из анекдота про мышей, чем на аргументацию технического специалиста.
Весь ваш текст можно свести к "давайте сделаем симметричное шифрование билета, а блок с паролями на ближайшие сто лет однократно раздадим в начале", то было бы просто и понятно всем. Даже букв писать меньше, чем вы в итоге написали. Как говорит один очень уважаемый профессор:
"Если вы, молодые люди, не сможете за 20 мин объяснить своей бабушке, почему матрица Грама в унитарном пространстве эрмитова, то — извините, мы не одной крови"
В качестве примера из коробки, возьмите любой гибридный алгоритм, ну тот же ECIES
ECIES это технологический концепт если хотите (для которого если не ошибаюсь даже RFC нет, только драфт) и реализация оного может даже в корне отличатся от рекомендаций
Ну а это как вообще следует понимать?
А теперь перейдем к моральной стороне вопроса.
Если вам кажется, что вас окружают идиоты, не понимающие вас, то начинать надо с себя — достаточно ли ясно вы высказываете собственные мысли? Телепаты в отпуске, как говорится.
В цивилизованным общением я, видимо, неточно выразился, и вы решили, что стиль "патриций с плебеем" — это тоже цивилизованно. Древний Рим очаг цивилизации же. Мне надо было попросить общаться культурно.
Учить мат-часть.
Вы очень нахальны молодой человек…
Это ваша проблема, что вы не хотите думать, не умеете их готовить.
Ну вот же, вы почти у цели…
открыл википедию… — Ааа… ну ладно тогда.
мы на хабре а не на пикабу, и видимо потому что у нас понятия "цивилизованно" рознятся.
Это называется высокомерие и снобизм. На Пикабу, кстати, никто не позволял себе общаться со мной подобным тоном, диалоги все выстраивались дружественно. И если вы сейчас подумали про "дружественный диалог обсуждения сисек", то это будет прекрасная иллюстрация моего посыла.
Очень странно объяснять это "дяденьке", перевалившему за 40 лет.
Восемь сообщений назад я просил… и далее по тексту моего предыдущего сообщения.
> Вы очень нахальны молодой человек…
Вы очень неточно предсказываете возраст по нику. Я моложе вас, но не настолько, чтобы это было существенно.
> вероятно в примере, где вы это нашли, там они (сессионные ключи) используются.
Я не искал примеров, а открыл википедию и прочитал про ECIES ru.wikipedia.org/wiki/ECIES. На всякий случай прочитал на английском и даже попытался сверить с немецким по формулам. Вроде везде одно и то же написано. Ну хорошо, давайте их не *сессионными* назовём, а *временными* — так лучше? У вас есть другой источник с другим алгоритмом?
>> Пример алгоритма в студию.
> А ключи от квартиры где деньги лежат вам не нужно случаем?
Эти требования сильно неравноценны. Под примером достаточно названия. ECIES не подходит, так как требует неспецифицированных модификаций. Можно ссылку на текст, где описывается подобная модификация любого другого алгоритма?
Я нашел вас на гитхабе, почитал коммиты. Вы вроде человек разумный, в теме разбираетесь, так почему не можете цивилизованно выстроить дискуссию? Я спрашиваю как в 144 битах уместить подтверждение того, что билет был сделан в кассе, а не на домашнем принтере. Я могу взять эллиптическую кривую над полем бит в 100-110 и применить сжатие точек, а в оставшиеся попытаться вписать дату и точки отправления/назначения, но я хочу увидеть ваш вариант, который еще компактнее и подписи не надо. Вы всё твердите, что есть крутые mixup'ы, гибридные алгоритмы, но не привели еще НИЧЕГО, подтверждающего ваши высказывания.
Пока троллингом занимаетесь вы. Я шесть сообщений назад просил явно показать схему. Пока что в ответ вижу «существуют гибридные схемы, всё просто, идите думайте». Т. е. отсутствие существенной информации. Так что у меня сложилось ощущение, что троллите здесь вы.
> Так вот, я вам официально заявляю, для гибридного шифрования (а тем паче подписи) совсем не нужно «передавать» куда-нибудь какой-либо сессионный ключ.
Пример алгоритма в студию.
У ECIES есть вполне конкретное описание, в котором к зашифрованному симметрично тексту прикладывается сессионный ключ для расшифрования, сделанный асимметрично. В этом суть большинства гибридных схем. По крайней мере википедия описывает именно такую схему. Если у вас есть другая — так опишите её или ссылку дайте, если лень писать.
Давайте возьмем всю ветку:
— Как вы, к слову, предлагаете сделать оффлайновый невзламываемый билет
— ЭЦП. Приватный ключ в TPM. В турникетах и проверяющих аппаратах — публичный.
— ЭЦП требует гораздо больше бит на штрихкоде.
— Хэш (сигнатура ЭЦП) может быть любого размера… И практически не зависит от длинны ключей.
Я перефразирую ваш тезис, а вы уж меня поправьте. Вы знаете схему, в которой можно подтвердить аутентичность сообщения Алисы (кассы) на стороне Боба (турникета), используя «хеш (сигнатуру ЭЦП)» любого размера. Если нет, и вы решаете другую задачу, то о чём вообще спор? Я говорю про конкретный проблему с билетами, меня не интересуют абстрактные алгоритмы.
Если думать/переделывать не хотим, в качестве примера из коробки, возмите любой гибридный алгоритм, ну тот же ECIES например. Тогда минимальный размер шифра равен blocklength лежащего в основе симметричного шифра (например в случае AES это было бы 128, в случае DES 64 бита), но это может быть любой симметричный блочный шифр
Какая разница, какой в основе лежит шифр, если с каждым сообщением нужно передавать сессионный ключ, который имеет размер, аналогичный подписи ECDSA? Ну или RSA, если угодно.
Давайте без подсказок вы прямо скажете, как именно можно проверить аутентичность message'а, вписавшись в 144 бита штрихкода билета? Ну чтобы не ходить вокруг да около, мало ли я опять чего не того сочиню.
Я формализую требования (мы ведь с Микротехом соперничаем?):
144 бита информации (пусть всё уйдет под подпись, черт уже с ним, с билетом)
Защищенность от перебора одним современным ПК
Возможность работы в условиях мобильного терминала (он слабый и вообще на батарейке)
Чем-то существенно лучше текущего решения с ежедневно сменяемым секретом
Использовать random padding чтобы внезапно получить короткую подпись в условиях мобильного терминала можно только если есть хоть какая-то предпосылка, что процесс сойдется за разумное время.
Учить мат-часть.
Я допускаю, что пропустил что-то из современных достижений криптографии, но в целом у меня с этим всё в порядке.
Это правда в случае расшифровки, не в случае сигнатуры (ну или вернее не совсем так, зависит от алгоритма).
Какой несимметричный алгоритм умеет поместить что-то полезное в 17 байт?
А можно про ту поломку поподробнее… Думается мне, что вы не поняли что там "поломали".
Подобрали приватный ключ, какие тут могут быть разночтения?
Нельзя, ибо мы говорим про асимметричную криптографию (private/public key). В противном случае (хеш с солью), тот кто умеет проверять, умеет и подписывать...
Это я прекрасно понимаю, я не понимаю ваш подход к проблеме
Здесь ни к чему, это вы притащили сюда эклиптику с DSA-подобным алгоритмом...
Объясните, пожалуйста, что именно вы предлагаете записать в 17 байт штрих кода и как это будет что-то гарантировать
Хэш (сигнатура ЭЦП) может быть любого размера… И практически не зависит от длинны ключей.
Сообщение любой длины хешируется, затем подписывается подписью. Именно эта подпись должна быть на билете для контроля, а не хеш сообщения или подписи. Она напрямую зависит от ключей, а точнее, размерности используемого поля.
32/64 битная ECC это ни о чем. 112 битная была поломана еще 9 лет назад. Да, тогда это было дорого, но это было давно, да и размерность той задачи сложнее в квадрате (2^112 против 2^64).
Можно просто писать на билете хеш с солью, но тогда к чему ваша фраза про «хеш (сигнатура ЭЦП)»?
q тоже берется не с потолка, оно должно быть делителем p — 1. А если оно им не будет, то работать совсем перестанет. Нельзя просто так взять и что-то поменять — обернуть в поверхность или функцию, необходимы
Я понимаю ваш посыл, что вы предлагаете как-то в процессе манипуляций с сообщением или промежуточным результатом уйти в меньшую размерность, но как — в упор не вижу. Пока мне кажется, что все навешанные сложности можно будет эффективно закешировать, сведя их эффект на нет, но это моё видение подхода, у вас оно может как-то отличаться.
Ну и отдельный вопрос. Я тут говорил про отрезание младших бит, вы вроде сказали, что это не то, а потом показываете пример с делением, которых по сути то же самое, только биты с другой стороны. Ну и перемешивание легкое, но это вроде несущественно. Это сбой аналогии или мы друг друга не понимаем?
Давайте так. Любая известная подпись — это функция на группе. Шифровать до или после бессмысленно — Ева сделает шифровку текста или дешифровку подписи и пойдет брутфорсить. Вставить шифровку (преобразование) внутрь функции подписи нельзя — шифротекст может вылететь из нашей группы, дальше группа его обрежет и восстановить его (проверить подпись) будет сложно. Но это вопрос открытый, допускаю, что может быть такое преобразование. Но это точно не AES-о подобное.
Энтропия подписи максимальна — сжимать её обратимо что сжимать zip архив. Сжимать её необратимо можно, но тогда проверяющей стороне потребуется выполнить проверку множества потенциальных подписей (результат обращения многозначен). Это примерно похоже на ваш метод, но удвоение сложности подбора удваивает стоимость проверки. Надо отдельно оценивать, сейчас я уже не в состоянии.
Дотошность — наше всё.
Я никак не могу найти подпись в ECIES — оно вроде как Encryption Scheme. Я видел в одном RFC что-то про аутентификацию, но оно отличалось от шифрования константой, а не алгоритмом. Покажите, пожалуйста, куда конкретно смотреть. Ну или напишите пару формул, вряд ли там что-то более сложное.
Мощность множества по оси X здесь — 350. Мощность множества по оси Y — 10^7. От пределов min/max их соотношение зависит практически никак. Как вы шифрованием переходите от одного к другому? Хешем — понятно, но шифрованием? Это же не функция на множестве действительных чисел, у нас дискретный случай.
На ум приходит только вариант с отрезанием младших бит, но он добавляет совсем немного сложности.
Вы меня тоже извините, если где перегнул палку.
Про Elgamal мне известно. Почему вы не продолжили и не написали, то q минимум 160? Я могу продолжить и сказать, что пара подписи (x,y) эллиптической кривой можно сократить до (x, bool), т.к. одному x соответствует максимум два y. А вот то, что можно это безболезненно уполовинить — это для криптографов, действительно, новость.
Мне нравится ваш переход к математике. Давайте
r = g ^ k (mod p)
s = ( H(m) — xr ) k^(-1) (mod p — 1)
H — хеш для данных
m — ваш билет
x — приватных ключ
k — случайное число. Остальное очевидно.
Куда вы тут шифр вставите? Как будете верифицировать подпись?
Про график. Если его нарисовать не в логарифмическом масштабе, а как есть, а потом вспомнить, что мы работаем над полем целых чисел, то одному x будет соответствовать несколько y. Это гарантирует коллизии и уменьшает оценку 2^80 для перебора. Только падение сложности от коллизий будет экспоненциальным, а усложнение от симметричного шифра — линейным.
В любом случае какой-либо симметричный алгоритм (шифратор или другой) такого не позволяет, ведь тогда он перестанет быть симметричным.
Вы можете прочитать нашу переписку и рассудить, кто прав, а кто нет?
P.S. Да, на решение этой задачки я потратил несколько лет :)
Я прозрачно подвожу вас к заключению, что вы создали офигительно крутую схему. Настолько же крутую, как вечный двигатель для физиков. И вас, похоже, ничего не смущает.
Да я не обижаюсь.
> Не важно что они у них появятся — главное что у них нет ECpriv.
Т. е. создать подпись они не могут. Еще раз без перебора подписи, тупо проверяя их прогоном через всё остальное (известные ECpub, AES ключи/алгоритм построения), подписать собственноручно созданный билет ВСЕ РАВНО не получится. Только перебор.
Они возьмут билет, расшифруют его ключом AES много тысяч раз, а дальше задача свелась к подбору ECpriv на 80 битах. При этом защиты от перебора уже нет.
ЭЦП нужна для того, чтобы проверяющая сторона не могла подпись подделать. В данном случае это турникет. Да, это выглядит странно, но тем не менее, с точки зрения ЭЦП стойкость тут — ECC над полем 2^80, потому как у турникета все симметричные ключи есть. У "хакеров" их, конечно нет, как нет, впрочем, и ECpub.
Другими словами, компрометация валидирующей стороны рушит схему, а в ЭЦП такого быть не должно. То есть это не ЭЦП. Это просто схема с симметричным шифрованием. Что не делает её непригодной, просто переусложненной (продолжение через два пункта).
Эллиптика ресурсоемкая (кстати, вы её тоже притянули!), но она необходима для компактности. ECDSA гарантирует (как может), что при вскрытии турникета жулик не получит ничего. Ваша схема не гарантирует.
Я практик с хорошим физмат образованием. Шесть лет назад я работал над практически идентичной проблемой, но мой "турникет" должен был работать в среде сотрудников с низкой социальной ответственностью (нет, это не известная идиома, просто совпадение). Из специализированных форумов я знаю, что "турникеты" были разобраны и тщательно изучены, в них были найдены все "скрытые" ключи и константы. Это жуликам не помогло.
Из-за возможных авторских, патентных и прочих опасений, вся криптография была написана руками с нуля по описаниям алгоритмов, начиная с длинной арифметики. Не вся лично мной, но достаточно много. Что еще добавить? Моя дипломная работа включала создание ИС для автоматического пояска уязвимостей в криптосхемах. Но работа откровенно слабая, а эта часть была побочной, так что хвалиться тут нечем, я только иллюстрирую свою вовлеченность в проблематику.
Неточно выразился, согласен. Имелась в виду схема "раздать всем набор ключей на год" (почти как у вас), а потом просто шифровать ими сообщения. 128 бит, все под полезную информацию (против 62 у вас) — как раз целый блок хорошего шифра. Остальное (16 бит) следует отдать под чексумму открытого текста (а-ля MAC). Тут вроде честные 2^128 получаются и можно многократно не шифровать — экономия батарейки. Ладно, фигня эта батарейка, механика принтера больше съест.
Да, я понял, что это средство от брута. Я, собственно согласился с вашей временной оценкой. Исходил я из того, что при выдаче билета у нас есть всего секунда на выполнение всех шифрующих итераций — никто не станет ждать билет минуту или час. Поэтому сверху есть секунда STM32 (кассир-контроллер) — снизу имеем 6,6 мкс на CUDA (хакер).
Есть класс атак Meet-in-the-middle. Из-за них, например, double DES бессмыслен. Я не говорю, что AES им подвержен, требования к памяти тут просто взрываются, но вдруг что-то есть? Беглый поиск показал, что все предлагают делать каскадное шифрование с разными ключами, а тут ключ один, получается, проблему никто не изучал. Вдруг после n-ой итерации мы получим промежуточное значение, сильно коррелирующее с изначальным или конечным? Мы тут как-никак 12 тыс проходов делаем. Ну, кстати, вот еще идея для усложнения перебора — использовать несколько ключей.
Тоже плохо выразился. Смотрите, вы шифруете точку кривой размером 80 бит. Делаете предположение, что в ней все биты абсолютно случайны, поэтому нам потребуется полный перебор. Верно ли это?
Теорема Хассе говорит, что в кривой у нас минимум 2^80 — 2^40 точек, так что здесь я поторопился с критикой, распределение более-менее случайное. Если, конечно, не забыть точки сжать, иначе в 80 битах у нас только 2^40 точек влезет. Но это всё несущественные нюансы.
Пора подводить итог. Я бы никогда не пришел к такой схеме, какие бы очевидные подсказки вы бы мне не давали, просто потому, что для меня это очевидно не ЭЦП. Поэтому я вас в тролли и записывал. Вы сделали интересный подход с усложнением перебора, но он уходит в terra incognita, и я на такое в коммерческом проекте не решился бы. К тому же есть более простое и эффективное решение с не меньшей стойкостью.
Жалко, что для прихода к этому пришлось потратить так много времени, текста и нервов. Вроде взрослые люди, а язык общий найти не можем. А знаете, что самое смешное? В день публикации этой чебурашки я ездил на электричке. Так вот на билете там — PDF417.
Я рад, что вы слезли наконец с коня. Право, было неудобно каждый раз поднимать голову.
Вы путаетесь в базовых понятиях. ЭЦП — это механизм, позволяющий с публичным ключом проверить подпись, которую можно сделать только с приватным ключом. В вашей системе это не так.
Для проверки вашей "подписи" необходимо помимо ECpub знать еще и ключ симметричного шифрования (иначе вы ничего не проверите). Именно эта пара и является публичным ключом, а не то, что вы себе нафантазировали. Просто по определению ЭЦП. Соответственно дальше задача идет по одному из двух путей (в зависимости от вашего алгоритма):
Если же мы будем рассматривать взлом со стороны, то вся схема свелась к той, что я уже упоминал — симметричный шифр с заранее распространенным блокнотом паролей. Только там мы сразу взяли простое шифрование с блоком 128, т.е. та схема была более стойкой.
Суммируя — вы придумали более ресурсоемкую схему с меньшей стойкостью. Ресурсоемкость, кстати, очень важна, ведь мобильным контроллерам приходится натурально таскать с собой запасные батарейки для терминалов, а тут вы эти терминалы усиленно разряжаете. Очень некрасиво по отношению к дамам.
Обратите внимание, я намеренно не использовал нигде конкретные реализации конкретных алгоритмов, а повествовал в наиболее общем виде. Это чтобы вы опять не стали опять ёрничать, что "эта схема не единственная, а всего одна из..., и вообще у вас ECIES не той системы".
Мы спорили про "ЭЦП может быть любой длины". Вы не смогли подтвердить это своё высказывание. В том, что вы можете сделать какую-нибудь схему для билетов электричек я, собственно, не сомневался — это достаточно тривиальная задача. Если, конечно, не пытаться сделать "её полностью оффлайновой" — то, с чего начиналась ветка, в которую вы так бесцеремонно влезли.
Ну и по мелочи:
Отталкиваться следует от возможностей мобильного терминала, а не "среднего железа". Я не профессионал, но, кажется, они поголовно делаются на STM32. Я бы выделил под подпись секунду, не более. STM32 аппаратно укладывается в 2500 тактов на блок (включая инициализацию), итого 14,4 тыс блоков в секунду (на 36MHz). На Geforce 1080 можно достичь 277 Gbps = 2,16 млрд блоков в секунду. Т.е. 6,6 микросекунд на секунду STM32. Ваша оценка оказалась близка к моей — у нас есть точки совпадения мнений :)
Имеется в виду хоть сколько-нибудь теоретическое исследование на тему, например, энтропии битов в точках кривой, иначе вот это утверждение:
является голословным. Вы же помните, что на флеше контроллеров, если хранить часто инкрементируемое значение, "младшие биты" быстрее "старших" изнашиваются? Ну или другой пример, что rand() % 100 не дает равномерно распределенные точки? А вдруг тут есть схожий эффект и вся ваша схема вообще в поле 2^8 вырождается? Да-да, бремя доказательства лежит на вас.
Существуют билеты стоимостью более 200 рублей (например, экспрессы). В общежитии МФТИ студенты не платят за кВт*ч, имеют по индивидуальному компьютеру и часто имеют бесплатный доступ к очень мощным вычислительным кластерам. В общем, не всё так однозначно.
У вас есть возражения по существу высказанных мною тезисов?
Это утверждение ложно. Все известные мне алгоритмы ЭЦП базируются на сложности задачи факторизации в группе (вычетов или точек эллиптической кривой). На выходе всех этих алгоритмов получаются элементы это группы. Соответственно их размер вообще никак не определяется приватным ключом, а определяется исключительно размером группы.
Вполне возможно, что у нас расхождение терминологии и под «подписью» вы подразумеваете нечто другое. Либо вы знаете какой-то неизвестный мне алгоритм.
> чем гарантирована «устойчивость» подписи? Не длинной ключей (вернее не напрямую)
Напрямую гарантируется неустойчивость, если неправильно выбрать ключ. Например, если взять его коротким (меньше N^(1/4)). Для понимания этого надо не RFC читать, а arXiv.org или хотя бы википедию.
> Нужно просто «немного» изменить алгоритм. <и далее>
А это уже просто смешно. Вы всерьез считаете себя достаточно компетентным, чтобы доказать стойкость такого решения? Или это будет алгоритм неуловимого Джо?
Давайте я резюмирую. Криптографы всей планеты пытаются создать наиболее компактные способы цифровой подписи данных, а тут врываетесь вы на коне и говорите, что «нужно просто „немного“ изменить алгоритм». Халява, что уж. «А мужики-то не знают».
Ну наконец-то стал понятен ход вашей мысли. Давайте я и вам поясню.
В ветке обсуждалось полностью оффлайновое решение проблемы. Проблема в том, что кассирам-контроллерам неудобно каждый день выполнять синхронизацию с центральным сервером. Я не знаю, почему, но вот примем такой факт. Далее demfoloro на вопрос "как сделать оффлайновый билет" отвечает "использовать ЭЦП", на что я говорю "подпись не влезет на штрихкод".
А далее со своим комментарием зачем-то влезаете вы. Во-первых, с ложным утверждением о том, что ЭЦП может быть любого размера (нет, не может — слишком короткая перестаёт быть ЭЦП и становится дурным хешем) и вообще предлагаете восьмибитный хеш. Человек со стороны может прочитать это только как "давайте добавим к сообщению короткий хеш, в нём и будет защита".
Потом идут пассажи про "хеш подписи" и ключи, которые по умолчанию сгенерируются для шифрования и подписывания, а надо не так. Последнее в общем случае неверено — все ключи ассиметричной криптографии, используемые для подписи, могут быть использованы для шифровки и наоборот. Я допускаю, что могут быть специализированные (только на один из алгоритмов) атаки на узкие подмножества ключей, но в целом ключи универсальны.
Всё стало понятно после упоминания MIKEY. Именно в RFC 3830 есть разные константы для разных типов TEK. Оказывается, вы всё это время говорили про протокол обмена ключами? Ну тогда, чтобы это было понятно остальным, необходимо об этом как-то упомянуть. Тем более, что отношения к решаемой задаче оно имеет сильно опосредованное — нам нужно вообще исключить обмен ключами, т.е. сделать его однократным. MIKEY для этого не предназначен, его ключи ДОЛЖНЫ протухать (см. RFC 3830, п. 9.2). На 144 битах штрихкода CBC режим на 128 бит использовать не удастся, придется взять ключ покороче. 32 битный ключ идеального шифратора придется менять "задолго до" 16 тыс билетов (см. там же). 64 битный протянет, конечно, сильно дольше, хотя в нём режим CBC сильно условен. Он вырождается в ECB, приходится первый блок целиком забивать белым шумом, а нам, вообще говоря, битов впритык хватает для передачи полезной информации. ECB же режим на 64 битах — это несерьезно.
Такая ситуация часто возникает, когда кто-то пытается
забить гвозди микроскопомиспользовать протокол для мультимедиа для обмена короткими сообщениями.Есть такое утверждение, что симметричное шифрование не следует быть использовать для аутентификации. Однако это слишком сильное требование, поэтому часто к нему добавляют "на протяжении длительного времени". Грамотные люди стараются пользоваться этим только в крайних случаях и аккуратно оценивают риски. Фраза "не умеете их готовить" мне больше напоминает сову-стратега из анекдота про мышей, чем на аргументацию технического специалиста.
Весь ваш текст можно свести к "давайте сделаем симметричное шифрование билета, а блок с паролями на ближайшие сто лет однократно раздадим в начале", то было бы просто и понятно всем. Даже букв писать меньше, чем вы в итоге написали. Как говорит один очень уважаемый профессор:
"Если вы, молодые люди, не сможете за 20 мин объяснить своей бабушке, почему матрица Грама в унитарном пространстве эрмитова, то — извините, мы не одной крови"
Ну а это как вообще следует понимать?
А теперь перейдем к моральной стороне вопроса.
Если вам кажется, что вас окружают идиоты, не понимающие вас, то начинать надо с себя — достаточно ли ясно вы высказываете собственные мысли? Телепаты в отпуске, как говорится.
В цивилизованным общением я, видимо, неточно выразился, и вы решили, что стиль "патриций с плебеем" — это тоже цивилизованно. Древний Рим очаг цивилизации же. Мне надо было попросить общаться культурно.
Это называется высокомерие и снобизм. На Пикабу, кстати, никто не позволял себе общаться со мной подобным тоном, диалоги все выстраивались дружественно. И если вы сейчас подумали про "дружественный диалог обсуждения сисек", то это будет прекрасная иллюстрация моего посыла.
Очень странно объяснять это "дяденьке", перевалившему за 40 лет.
Скатертью дорога
> Вы очень нахальны молодой человек…
Вы очень неточно предсказываете возраст по нику. Я моложе вас, но не настолько, чтобы это было существенно.
> вероятно в примере, где вы это нашли, там они (сессионные ключи) используются.
Я не искал примеров, а открыл википедию и прочитал про ECIES ru.wikipedia.org/wiki/ECIES. На всякий случай прочитал на английском и даже попытался сверить с немецким по формулам. Вроде везде одно и то же написано. Ну хорошо, давайте их не *сессионными* назовём, а *временными* — так лучше? У вас есть другой источник с другим алгоритмом?
>> Пример алгоритма в студию.
> А ключи от квартиры где деньги лежат вам не нужно случаем?
Эти требования сильно неравноценны. Под примером достаточно названия. ECIES не подходит, так как требует неспецифицированных модификаций. Можно ссылку на текст, где описывается подобная модификация любого другого алгоритма?
Я нашел вас на гитхабе, почитал коммиты. Вы вроде человек разумный, в теме разбираетесь, так почему не можете цивилизованно выстроить дискуссию? Я спрашиваю как в 144 битах уместить подтверждение того, что билет был сделан в кассе, а не на домашнем принтере. Я могу взять эллиптическую кривую над полем бит в 100-110 и применить сжатие точек, а в оставшиеся попытаться вписать дату и точки отправления/назначения, но я хочу увидеть ваш вариант, который еще компактнее и подписи не надо. Вы всё твердите, что есть крутые mixup'ы, гибридные алгоритмы, но не привели еще НИЧЕГО, подтверждающего ваши высказывания.
> Так вот, я вам официально заявляю, для гибридного шифрования (а тем паче подписи) совсем не нужно «передавать» куда-нибудь какой-либо сессионный ключ.
Пример алгоритма в студию.
У ECIES есть вполне конкретное описание, в котором к зашифрованному симметрично тексту прикладывается сессионный ключ для расшифрования, сделанный асимметрично. В этом суть большинства гибридных схем. По крайней мере википедия описывает именно такую схему. Если у вас есть другая — так опишите её или ссылку дайте, если лень писать.
Давайте возьмем всю ветку:
— Как вы, к слову, предлагаете сделать оффлайновый невзламываемый билет
— ЭЦП. Приватный ключ в TPM. В турникетах и проверяющих аппаратах — публичный.
— ЭЦП требует гораздо больше бит на штрихкоде.
— Хэш (сигнатура ЭЦП) может быть любого размера… И практически не зависит от длинны ключей.
Я перефразирую ваш тезис, а вы уж меня поправьте. Вы знаете схему, в которой можно подтвердить аутентичность сообщения Алисы (кассы) на стороне Боба (турникета), используя «хеш (сигнатуру ЭЦП)» любого размера. Если нет, и вы решаете другую задачу, то о чём вообще спор? Я говорю про конкретный проблему с билетами, меня не интересуют абстрактные алгоритмы.
Какая разница, какой в основе лежит шифр, если с каждым сообщением нужно передавать сессионный ключ, который имеет размер, аналогичный подписи ECDSA? Ну или RSA, если угодно.
Мне изначально не нужна была вторая часть.
Давайте без подсказок вы прямо скажете, как именно можно проверить аутентичность message'а, вписавшись в 144 бита штрихкода билета? Ну чтобы не ходить вокруг да около, мало ли я опять чего не того сочиню.
Я формализую требования (мы ведь с Микротехом соперничаем?):
Использовать random padding чтобы внезапно получить короткую подпись в условиях мобильного терминала можно только если есть хоть какая-то предпосылка, что процесс сойдется за разумное время.
Я допускаю, что пропустил что-то из современных достижений криптографии, но в целом у меня с этим всё в порядке.
Какой несимметричный алгоритм умеет поместить что-то полезное в 17 байт?
Подобрали приватный ключ, какие тут могут быть разночтения?
Это я прекрасно понимаю, я не понимаю ваш подход к проблеме
Объясните, пожалуйста, что именно вы предлагаете записать в 17 байт штрих кода и как это будет что-то гарантировать
Для чего этот хеш?
32/64 битная ECC это ни о чем. 112 битная была поломана еще 9 лет назад. Да, тогда это было дорого, но это было давно, да и размерность той задачи сложнее в квадрате (2^112 против 2^64).
Можно просто писать на билете хеш с солью, но тогда к чему ваша фраза про «хеш (сигнатура ЭЦП)»?