Как зашифровать на PHP строку в токен 32 символа?

Question

[MakarMS]

Изначально задача стоит так, чтобы зашифровать массив (строка JSON) на пхп в красивый токен 32-64 символа (на подобие хэширования MD5) и иметь возможность его расшифровать. Этот токен будет находится в URL, поэтому и такой длинны. Можно ли это как-то реализовать?

Answer 1

[ThunderCat]

зашифровать массив (строка JSON) на пхп в красивый токен 32-64 символа (на подобие хэширования MD5) и иметь возможность его расшифровать.

Надеюсь вы в курсе, что MD5 необратимый алгоритм? Именно по этому с его помощью можно получить строку фиксированной длинны (при этом получая небольшой процент коллизий) от строки любой длинны. Очевидно, что строку произвольной длинны, больше чем 32 или 64 символа, невозможно упаковать в стандартную длину (например 1000 символов запаковать в 64, иначе нафига нужны бы были архиваторы).

Однако, можно сделать иначе: На сервере хранить строку (например в бд), а ключом к ней будет хэш от этой строки, можно даже с солью.

Answer 2

[rPman]

возможность его расшифровать

это о чем? восстановить исходную строку из 64 символов? если изначальная строка будет не больше этого размера то это возможно обычным шифрованием с ключом, алгоритмов тьма, популярный - асимметричное шифрование

Если изначальная строка длиннее, то либо нужно ее упаковать (алгоритмов тоже тьма, включая тех что работают с использованием прошлых данных, например diff возвращает разницу между двумя текстовыми файлами, построчно)

Ну и само собой невозможно любые данные упаковать в фиксированный объем. Где то нужно хранить изначальные данные и тогда твой токен будет просто идентификатором

Comments

[mayton2019]

Я вот посмотрел. Youtube использует линки следующего вида www.youtube.com / watch ? v=3bmF83e0dss

11 символов на хеш из набора (приблизительно) base64. Это где-то по 6 бит на символ. Итого 66 бит.
Это очень близко к 64-битному целому. Возможно youtube где-то отсекает разрядную сетку и не все
биты используются. Это было-бы разумно.

Для них коллизию двух видосов можно было-бы ожидать после 4х миллиардной загрузки.

В случае автора - восстановить оригинальный документ наверное невозможно. Мы не знаем его длины.
Но можно поступать как youtube. Хешировать и вести базу всех json документов. Уж если youtube делает
то почему Макару нельзя.

[rPman]

маловероятно что гугл использует хеш, шифрование - да, возможно, чтобы исключить отслеживание количества загруженных видео при использовании простого autoincrement для следующих идентификаторов

поэтому у них не может быть коллизий, идентификатор видео назначается уникальным

p.s. есть алгоритмы генерации uuid (128bit) где гарантируется отсутствие коллизий без использования централизованной выдачи идентификаторов, так же есть алгоритмы по проще, когда количество нод в кластере (выдающим идентификаторы) ограничено заранее и в итоговом числе для номера ноды выделены соответствующие биты.

[Stalker_RED]

mayton2019, rPman, у ютуба там не просто хэш
https://youtu.be/gocwRvLhDf8

https://habr.com/ru/company/virgilsecurity/blog/311676/
см. упрощенный вариант - snowflake https://habr.com/ru/post/334994/

[mayton2019]

Stalker_RED, ну я не против. Только мне кажется что у автора-то вопрос другой. Про шифрование-дешифрование а мы зашли в область генерации распределенных ключей.

Жаль что он нас не читает и ничего не комментирует.