Хорошо, так как вы пояснили, что вы пытаетесь сделать, я переписал свой ответ.
Подводя итог: используйте настоящий алгоритм шифрования.
Сначала позвольте мне перейтипочему ваша система хеширования - плохая идея.
Что такое ваша система хеширования?
Насколько я понимаю, ваша предложенная система выглядит примерно так:
Ваша встроенная системаСистема (которую я назову C) посылает какие-то данные с пространством значений 10 ^ 11.Эти данные должны храниться в тайне при передаче на какой-либо сервер (который я назову S).
Ваше предложение состоит в том, чтобы отправить значение hash(salt + data) в S. Затем S использует радужную таблицу для обратногоэто хеш и восстановить данные.salt является общим значением, известным как C, так и S.
Это алгоритм шифрования
Алгоритм шифрования, когда вы его сводите, любой алгоритм, который дает вамконфиденциальность .Поскольку ваша цель - конфиденциальность, любой алгоритм, который удовлетворяет вашим целям, является алгоритмом шифрования , включая этот.
Это очень плохой алгоритм шифрования
Во-первых, существует неизбежный шанс столкновения .Более того, набор конфликтующих значений меняется каждый день.
Во-вторых, дешифрование требует очень много ресурсов процессора и памяти даже для легитимного сервера S. Изменение соли еще дороже.
В-третьих, хотя ваша заявленная цель - избежать управления ключами, ваша соль - это ключ !Вы вообще не решили управление ключами;любой, у кого есть соль, сможет взломать сообщение так же хорошо, как вы.
В-четвертых, его можно использовать только от C до S. Ваша встроенная система C не будет иметь достаточно вычислительных ресурсов для обратного хеширования и можеттолько отправлять данные.
Это не быстрее реального алгоритма шифрования на встроенном устройстве
Большинство алгоритмов безопасного хеширования столь же вычислительно дороги, как и разумный блочный шифр, если не хуже.Например, SHA-1 требует выполнения следующих действий для каждого 512-битного блока:
- Выделение 12 32-битных переменных.
- Выделение 80 32-битных слов для расширенного сообщения
- 64 раза: выполнить три поиска в массиве, три 32-разрядных xors и операцию поворота
- 80 раз: выполнить до пяти 32-разрядных двоичных операций (некоторая комбинация xor и, или, не, а и в зависимости от раунда);затем вращение, поиск в массиве, четыре добавления, другое вращение и несколько загрузок / сохранений памяти.
- Выполнение пяти 32-разрядных добавлений по два дополнения
Существует один блок на 512-биты сообщения, плюс возможный дополнительный фрагмент в конце.Это 1136 двоичных операций на блок (не считая операций с памятью) или около 16 операций на байт.
Для сравнения, алгоритм шифрования RC4 требует четырех операций (три добавления, плюс xor в сообщении) на байт, плюс два чтения массива и два записи массива.Для этого также требуется только 258 байт рабочей памяти против пика в 368 байт для SHA-1.
Управление ключами является фундаментальным
В любой системе конфиденциальности у вас должен быть какой-то секрет.Если у вас нет секретов, то любой другой может реализовать тот же алгоритм декодирования, и ваши данные будут доступны миру.
Итак, у вас есть два варианта, где хранить секретность.Один из вариантов - сделать секретными алгоритмы шифрования / дешифрования.Однако, если код (или двоичные файлы) для алгоритма когда-либо утечет, вы потеряете - такой алгоритм довольно сложно заменить.
Таким образом, секреты, как правило, легко заменить - это то, что мы называемключ.
Предполагаемое использование хеш-алгоритмов потребует соли - это секрет only в системе и, следовательно, ключ. Нравится вам это или нет, вам придется тщательно управлять этим ключом. Заменить его намного сложнее, если он утек, чем другие ключи - вам приходится тратить много часов ЦП на создание новой радужной таблицы при каждой ее замене!
Что делать?
Используйте настоящий алгоритм шифрования и потратьте некоторое время на размышления об управлении ключами. Эти проблемы были решены ранее.
Сначала используйте реальный алгоритм шифрования. AES был разработан для высокой производительности и низких требований к оперативной памяти. Вы также можете использовать потоковый шифр, такой как RC4, как я уже упоминал ранее - однако при использовании RC4 следует остерегаться того, что вы должны отбросить первые 4 килобайта или около того выходных данных шифра, иначе вы будете уязвимы к тому же атаки, которые преследовали WEP.
Во-вторых, подумайте об управлении ключами. Один из вариантов - просто записать ключ в каждого клиента и физически выйти и заменить его, если клиент скомпрометирован. Это разумно, если у вас есть легкий физический доступ ко всем клиентам.
В противном случае, если вас не волнует атака «человек посередине», вы можете просто использовать Обмен ключами Диффи-Хеллмана для согласования общего ключа между S и C. Если вас это беспокоит Что касается MitM, то вам нужно начать смотреть на ECDSA или что-то для аутентификации ключа, полученного от обмена DH - будьте осторожны, однако, когда вы начинаете идти по этому пути, легко ошибиться. Я бы порекомендовал реализовать TLS на этом этапе. Это не выходит за рамки возможностей встроенной системы - действительно, существует число встроенных коммерческих (и с открытым исходным кодом) библиотек доступно уже. Если вы не внедрили TLS, то, по крайней мере, попросите профессионального криптографа просмотреть ваш алгоритм перед его реализацией.