Хорошо, поскольку вы пояснили, что пытаетесь сделать, я переписал свой ответ.
Подводя итог: используйте настоящий алгоритм шифрования.
Во-первых, позвольте мне объяснить, почему ваша система хеширования — плохая идея.
Какая у вас система хеширования?
Насколько я понимаю, предлагаемая вами система выглядит примерно так:
Ваша встроенная система (которую я буду называть 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-разрядных исключающих операции и операцию поворота.
- 80 раз: выполнить до пяти 32-битных бинарных операций (некоторая комбинация xor, and, or, not и and в зависимости от раунда); затем поворот, поиск в массиве, четыре добавления, еще один поворот и несколько загрузок/сохранений памяти.
- Выполнить пять 32-битных дополнений до двух
На каждые 512 бит сообщения приходится один фрагмент плюс возможный дополнительный фрагмент в конце. Это 1136 бинарных операций на чанк (не считая операций с памятью), или около 16 операций на байт.
Для сравнения, алгоритм шифрования RC4 требует четырех операций (три сложения плюс операция xor над сообщением) на байт, плюс два чтения массива и две записи массива. Для этого также требуется всего 258 байт оперативной памяти по сравнению с 368 байтами для SHA-1.
Управление ключами является фундаментальным
При любой системе конфиденциальности у вас должен быть какой-то секрет. Если у вас нет секретов, то любой другой может реализовать тот же алгоритм декодирования, и ваши данные становятся доступными для всего мира.
Итак, у вас есть два варианта, куда поместить секретность. Один из вариантов — сделать алгоритмы шифрования/дешифрования секретными. Однако, если код (или двоичные файлы) для алгоритма когда-либо просочится, вы проиграете — такой алгоритм довольно сложно заменить.
Таким образом, секреты обычно легко заменяются — это то, что мы называем ключом.
Предлагаемое вами использование хеш-алгоритмов потребует соли — это единственный секрет в системе и, следовательно, ключ. Нравится вам это или нет, вам придется аккуратно обращаться с этим ключом. И его намного сложнее заменить в случае утечки, чем другие ключи - вам придется тратить много процессорных часов на создание новой радужной таблицы каждый раз, когда она изменяется!
Что вы должны сделать?
Используйте реальный алгоритм шифрования и потратьте некоторое время на размышления об управлении ключами. Эти вопросы были решены ранее.
Во-первых, используйте реальный алгоритм шифрования. AES был разработан для обеспечения высокой производительности и низких требований к оперативной памяти. Вы также можете использовать потоковый шифр, такой как RC4, как я упоминал ранее. Однако при использовании RC4 следует остерегаться того, что вы должны отбросить первые 4 килобайта или около того вывода из шифра, иначе вы будете уязвимы для того же самого. атаки, которые заражают WEP.
Во-вторых, подумайте об управлении ключами. Один из вариантов — просто записать ключ в каждый клиент и физически выйти и заменить его, если клиент скомпрометирован. Это разумно, если у вас есть легкий физический доступ ко всем клиентам.
В противном случае, если вас не интересуют атаки «человек посередине», вы можете просто использовать обмен ключами по Диффи-Хеллману для согласования общего ключа между S и C. Если вас беспокоят MitM, вам нужно начать искать ECDSA или что-то еще для аутентификации ключа, полученного при обмене D-H. Помните, что когда вы начинаете идти по этому пути, легко ошибиться. Я бы порекомендовал внедрить TLS в этот момент. Это не выходит за рамки возможностей встроенной системы — действительно, существует количество встроенных коммерческих (и открытых источник) библиотеки доступно уже. Если вы не реализуете TLS, то по крайней мере попросите профессионального криптографа просмотреть ваш алгоритм перед его внедрением.
person
bdonlan
schedule
03.02.2011
