Имеется небольшой список соответствия реальных идентификаторов и их кодированных версий, создаваемых с целью защиты от подбора последовательных элементов:
И так далее.
Похоже ли это на какой-нибудь известный алгоритм? Я пробовал функции "pseudo_encrypt" и "pseudo_encrypt24" из "PostgreSQL" - они не подходят. Если на поверхности решения нет, сколько предположительно может стоить его нахождение?
Роман Мирр, имеется информация, что сайт, на котором элементы защищаются подобным образом, использует данную СУБД - представители данного сайта постоянно декларируют это на всевозможных IT-конференциях; возникло предположение, что реальный идентификатор кодируется с помощью некой хранимой процедуры. В открытом доступе были найдены "pseudo_encrypt" и "pseudo_encrypt24", однако они не подошли.
Пары соответствий были выявлены следующим образом: на исследуемом сайте имеются два типа элементов, A и B; идентификаторы обоих кодируются. Интересует механизм последовательного подбора элементов типа A. По недосмотру разработчиков сайта в HTML-коде "засвечиваются" реальные идентификаторы элементов типа B - оттуда и были извлечены пары соответствий. Предполагается, что аналогичный алгоритм используется и в элементах типа A. Осталось лишь выявить его по данным парам соответствий.
можно отбросить алгоритмы которые выдают фиксированное число символов после шифрования. Можно обратить внимание на изменение количества выходных данных , у разных данных, минимум 7 максимум 9. Если память не изменять довольно много алгоритмов страдали от проблемы не изменения криптографической стойкости при повторном шифровании. Можете искать
stictt, именно поэтому и было обращено внимание на "pseudo_encrypt" - число знаков выдаваемых им значений нестабильно и как бы подпадает под данный случай. Возможно, используется некая секретная модификация данной функции.
Также имеется предположение, что на сайте идентификаторы выбираются случайным образом, по типу "rand(1000000000,1800000000)"; однако при взгляде на колоссальные объёмы данных на исследуемом сайте в этом появляются сомнения, так как с возрастанием количества данных на сайте (а ежедневно там появляются миллионы новых элементов) возрастает и вероятность коллизии, требующей, в свою очередь, множественной и создающей высокую нагрузку на сервер проверки существования нового идентификатора в базе данных.
kopytse, Если вы не прозженный математик или у вас нет кучи денег, занятие это бесмысленное. Даже у меня не самого умного человека, появлялась мысль использовать комбинацию блочных и потоковых видов шифрования с разной степенью наложения при этом "Соля" данные в определенной части в зависимости от ключа. Теоретически этим можно было бы избавится от многих проблем. А что говорить уже про совсем современных людей которые собаку сожрали на этой деятельности
Средний
