Упакованный хеш

[Geebrox]

Как-то наткунулся на тему от Daniel_Cortez про упаковку хеша SHA256. Всё тщательно изучил и реализовал. Проблема возникает при сохранении упакованного хеша в базе данных. После сохранение и загрузки упакованного хеша в переменную, оно полностью меняется. После чего игрок не может пройти авторизацию. Вопрос, вообще можно ли сохранять такие строки в базе данных, просто после упаковки они становятся иероглифами. Примечание, в базе данных кодировка UTF-8.

[VVWVV]

Может быть немного скринов и кода?

[Geebrox]

Тему можно закрывать, решение не найдено.
Альтернативное решение: использовать UNHEX для хешов в базе данных (@Deimos) <- Но это ещё не протестировано.

[DeimoS]

использовать UNHEX для хешов в базе данных (@Deimos) <- Но это ещё не протестировано.

*Протестировано и прекрасно работает :)
Хотя, думаю, можно и лучше вариант реализовать (благо в MySQL полно функционала для конвертирования данных), просто я никогда этим функционалом MySQL особо не интересовался и рассказал лишь о том, о чём когда-то читал "вскользь".

Если у кого-то будет что-то добавить касаемо вопроса, можете отписать в личку и отрою тему.
Закрыто.

[Daniel_Cortez]

Удалил свою тему с функциями упаковки/распаковки хешей - всё равно проку от них немного, если в MySQL есть встроенные средства для хранения хешей в упакованном виде.
К слову о тех средствах...

Тему можно закрывать, решение не найдено.
Альтернативное решение: использовать UNHEX для хешов в базе данных (@Deimos) <- Но это ещё не протестировано.

На самом деле, использование UNHEX совершенно необязательно, понадобится только функция HEX для распаковки бинарных данных обратно в строку.

Скажу сразу, я не работаю с модами на MySQL и у меня нет под рукой сервера с одним из таких модов, чтобы всё протестировать, равно как и нет времени на подготовку всего этого. Всё, что у меня есть на данный момент - это XAMPP с phpmyadmin и сервером MySQL в комплекте; этого должно хватить, чтоб хотя бы проверить работу запросов к БД.

Итак, допустим, у нас есть таблица, в которой одно поле отведено под ID (ключ) и другое под хеш-сумму в бинарном (упакованном) виде.

CREATE TABLE `test` (    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,     /* SHA-256 выдаёт 32 байта (256 бит) данных,     * поэтому длина бинарной строки тоже должна быть равна 32     */    `data` BINARY(32) NOT NULL,    PRIMARY KEY (`id`))

Едем дальше, упаковка и сохранение хеша в БД должна выглядеть примерно так:

INSERT INTO `test`(`data`) VALUES (0xE3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855)

Как видно из примера, конвертация строки в данные (бинарную строку) производится в обход функции UNHEX - достаточно просто добавить перед хешем префикс "0x".
Т.е. примерно так должен составляться запрос:

static const fmt_str[] = "INSERT INTO `test`(`data`) VALUES (0x%e)";new string[sizeof(fmt_str) + (-2 + 64)];SHA256_PassHash(/* ... */, /* ... */, string, sizeof(string));mysql_format(mysql_connection, string, sizeof(string), fmt_str, string);

И запрос для выгрузки хеша из БД:

SELECT HEX(`data`) FROM `test` WHERE `id`=1

Здесь функция HEX конвертирует бинарные данные в обычную строку, которую можно получить с помощью cache_get_value_name.

Таким нехитрым(?) методом можно заставить хеш занимать в 4 раза меньше места в БД, всё с помощью встроенного функционала MySQL.

[DeimoS]

Как видно из примера, конвертация строки в данные (бинарную строку) производится в обход функции UNHEX - достаточно просто добавить перед хешем префикс "0x".

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