Сила дайджеста сообщений: конкатенация и итерация - PullRequest
1 голос
/ 15 февраля 2011

Если у меня есть 3 поля, которые открываются «в открытом виде», и я хочу подписать эти поля цифровой подписью, чтобы убедиться, что они не были подделаны с помощью безопасной хэш-функции.У меня есть 2 варианта:

  1. Я могу объединить 3 поля и использовать дайджест, чтобы хэшировать все как одну строку, то есть хэш (field1 + field2 + field3 + salt)
  2. Я могу итеративно хешировать отдельные результаты, то есть хеш (field1 + hash (field2 + hash (field3 + salt)))

Очевидно, что подход 1 будет быстрее, чем подход 2, но будет приближаться2 Является ли кто-нибудь «более сильным» с точки зрения того, чтобы помешать кому-либо обнаружить ценность соли путем обратного инжиниринга входных данных из широкого спектра выходных данных (я верю, но стоит ли это дополнительных затрат процессора)?

Ответы [ 2 ]

1 голос
/ 15 февраля 2011

Сначала я должен выпустить стандартный комментарий о том, что хэширование не подписывает .Цифровая подпись - это процесс, который включает ключи и верификаторы.Здесь вы просто хотите хэшировать некоторые данные и хранить хеш-значение в «безопасном» месте, чтобы вы могли распространить целостность хеш-значения на хешированные данные: убедитесь, что хеш-значение не подделано, и, повторно вычисляя хеш для элементов данных и находя то же самое значение хеш-функции, вы обретаете уверенность в том, что элементы поля также не были изменены.

Затем я должен выпустить второй стандартный комментарий, которыйчто нет проблем с производительностью, пока не будет должным образом измерено в реальных условиях .Хеширование быстро.Даже с не очень быстрой функцией хеширования базовый ПК сможет выполнять миллионы операций хеширования в секунду.

Теперь я вижу, что вы хотите использовать «соль».Соль - это часть общедоступных данных, цель которых состоит в том, чтобы быть индивидуальными для каждого экземпляра, чтобы предотвратить разделение затрат на дешифрование.Это имеет смысл в установке, где есть некоторые зашифрованные данные;насколько я вижу из того, что вы описываете, в вашей задаче нет ничего зашифрованного.

... если только вы на самом деле не имеете в виду, что вы будете хранить свою "соль" в секрете и хранить хеш-значение вместе споле данных.В этом случае мы больше не говорим о хешировании.Ваша «соль» будет более уместно называться «ключом», поскольку она должна оставаться конфиденциальной.И вам нужен не хеш, а MAC .Иногда MAC называют «подписью».Это не правильно, но менее неправильно, чем называть хеши «сигнатурами».Если вам нужен MAC (а ваша соль - это ключ), то вам не следует использовать ни одну из ваших конструкций.Построить MAC нелегко: многие конструкции ручной работы терпят неудачу, когда речь заходит о безопасности.К счастью, существует стандартный MAC под названием HMAC .HMAC использует основную хеш-функцию (используйте SHA-256) и ключ, который превращает их в MAC.HMAC поддерживается многими криптографическими библиотеками.

1 голос
/ 15 февраля 2011

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

Кто может сказать, стоит ли это "дополнительных затрат на процессор"? Как часто вы будете этим заниматься? Придется ли вам покупать больше процессоров? Сколько вы платите за электричество? С другой стороны, сколько это будет стоить вам, если кто-то успешно подделает данные, «защищенные» домашним алгоритмом?

...