А теперь можно я резюмирую… то, что вы не осилили на протяжении всей ветки.
Берем 144 «заявленных» бита, и забираем:
- 26 на время начала действия билета (не от начала эпох, а как diff от точки X, например времени ввода в эксплуатацию), 26 бит покрывают с лихвой десять лет с точностью до 10-ти секунд (
2**26 > 10*366*24*60*10); - 18 на «откуда», т. е. точку отправления (
2**18 == 262144остановок, что я думаю раз в 10-ть больше чем требуется) - 18 на «куда»
Имеем в остатке 82 бита 82 == 144-26-18-18;
Берем оригинальный ECIES (хоть отсюда). Для симметричной составляющей берем например AES, twofish и т.д, с любой длинной ключей и «хомячим» в блок 80 бит.
И оборачиваем это в миксап типа:
Который повторяет «шифрование» ENC/AES(key, iv, HMAC(Hash, text), prevIter) необходимое количество раз Cnt.
Под ENC понимается «стандартные» ECDLP, ElGamal (с блоком в 40 бит) и т.д. Под «необходимым» количеством повторов, понимается снижение скорости проверки подписи до приемлемой. Например, на какой-нибудь число-дробилке — за 10 микросекунд (что соответствует средней железке ~ 250 микросекунд).
Остальное оставляем как оно есть, т.е. хоть те же «стандартные» HMAC, KDF и т.д. Хотя что здесь считать стандартным, ибо их столько…
Подписываем ECIES(MY_DL_EncrypAlgo/Cnt), с private (ECpriv) / public(ECpub) ключами любой длинны.
Имеем подпись длинной 80 бит.
Т.к. алгоритм неразрывный, перебор подписи под известный ECpub (и «известные» симметричный ключ key, iv, и HMAC(Hash, text)) — будет полным, т.е. даже зная все составляющие (кроме ECpriv), необходим итеративный брут всех значений, до максимально 280.
Т.е. грубо чтобы подписать любой билет (не зная ECpriv), нам нужно перебрать максимум 280 вариантов (1208925819614629174706176 или 1.2e+24), проверив каждый, используя известный ключ (ECpub) и затратив 10µs на каждой итерации (на очень хорошем железе).
(2**80) * 10µs / 1e6 / 60 / 60 / 24 / 365 — это порядка 383347862638 (или 3.8e+11) CPU-лет на дорогой и прожорливой число-дробилке (на поток).
На настоящий момент неизвестно ни одного алгоритма/атаки на подбор приватного ключа ECIES (кроме мягких, типа CCA2 и т.д., которые здесь не работают от слова совсем).
Да, если вы определите понятие, что такое здесь «стойкость решения»… Только не «доказать», а показать что она выше требуемого значения. Т.к. вам всё нужно разжёвывать: я например не могу в уме сосчитать ln(5), но могу точно сказать/доказать что он больше 1.
Они-то может и пытаются, только видимо осилить все пограничные «условия», риски и области применения, для которых они де «пытаются», вам по всей видимости не дано… Т.е. например, разницу между «подписать» билет стоимостью 12 рублей и «подписать» какую-нибудь транзакцию на несколько миллионов, вы не видите в принципе? Я вам помогу немного — в одном случае рентабельность сего действа убегает в минус после уже каких-то шести кВт-часов.
Источник