Если я правильно прочитал вики, алгоритм позволяет узнать любой член последовательности из изначального состояния, но не наоборот. Т.е. условно, получив из ID = 5 её представление 2348203948, которое мы показываем пользователю, мы обратно сделать не сможем, придется где-то хранить это представление в дополнение к оригинальной ID.
Разве получится с его помощью генерить криптостойкие 32 или 64битные последовательности? Если будем брать не все биты, то не сможем восстановить оригинальный номер, а если брать маленькие простые числа, то их факторизовать можно чуть ли не на бумажке
Ради айдишек городить такую инфраструктуру, мне кажется, никто не будет, проще заюзать BPS. К тому же, у него есть один интересный побочный эффект — смена ключа мгновенно меняет все видимые ID на другие. Не уверен, что это прям крутое преимущество, но где-то может пригодиться, например чтоб кеши какие то сбросить
При чем тут security through obscurity? Я могу в открытую опубликовать алгоритм шифрования ID, но ключ останется у меня. И это никак не ослабит защиту от прямого перебора. Хочется перебирать все возможные варианты — никто не запрещает, но по порядку это сделать не получится, придется шерстить весь диапазон.
Мы именно это и делаем, мы уменьшаем размер блока, Но функцией перестановки остается AES у которого всегда 128 бит. Статья как раз о том как не трогая AES добиться стойкости на блоках меньше 128 бит
Прежде всего там, где внедрить нормальное шифрование сложно или невозможно из-за проблем совместимости. В каких-нибудь XML или других текстовых протоколах и в других местах где всё завязано на формат данных и который менять будет себе дороже
Мы же по сути строим сеть Фейстеля для ограниченного множества значений, так что просто блочный шифр с размером блока равным размеру множества. Так что да, тут всё честно
Шифруются ведь именно индексы, получается Akon32 прав.
Если к *опе приспособить сопроцессор фирмы Крэй
Можно $рать в два унитаза в сорок тысяч раз быстрей!
С днем рождения!