Единственное упомянутое вами ограничение - слабое влияние на обработку - но вы не предоставили подробных сведений о силе требуемого алгоритма.
Кроме того, если шифрование реализовано в PHP, то оно будет на несколько порядков менее эффективным, чем собственный код, как предусмотрено расширением mcrypt (и другими).
Зашифрованное значение будет сохранено как session_id
Почему ????
Идентификатор сеанса генерируется случайным образом и, следовательно, не является предсказуемым / предполагаемым. А сеансы предоставляют механизм для хранения данных на сервере. Если проблема заключается в том, чтобы поддерживать защищенные данные вне сеанса из-за ограничений общего хостинга, то это , а не правильный способ решения проблемы.
Существуют собственные реализации PHP различных алгоритмов, очевидным выбором является TEA, а str_rot13 () доступен, даже если расширения mcrypt / openssl недоступны. Но я не вижу логического применения этих методов к любой проблеме.