Использование RSA для хэша

я обдумываю создание хэш-функции (например, md5 или sha1) с использованием алгоритма RSA crypto. Мне интересно, есть ли какие-либо очевидные причины, по которым этот алгоритм не будет работать:

  1. генерация открытых / закрытых ключей RSA.
  2. отбросить закрытый ключ, никогда не хранить его вообще.
  3. начните с хэша с длиной размера блока для шифрования RSA.
  4. зашифровать сообщение с помощью открытого ключа, по одному блоку за раз.
  5. для каждого зашифрованный блок сообщения, аккумулируйте его в хэш с помощью указанного алгоритма (возможно, комбинации+, xor и т. д.).)

чтобы проверить, что сообщение имеет тот же хэш, что и сохраненный хэш, используйте сохраненный открытый ключ и повторите процесс.

возможно ли это, безопасно и практично?

Спасибо за любые комментарии.

6
encryption hash rsa

4 ответов

уже есть хэши, которые делают по существу это, за исключением, возможно, не с алгоритмом RSA в частности. Они называются криптографическими хэшами, и их основная точка заключается в том, что они криптографически безопасны - это означает, что та же самая сила и ориентированная на безопасность мысль, которая входит в криптографические функции открытого ключа, также вошла в них.

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

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

SHA-512-отличный криптографический хэш и вероятно, заслуживает вашего внимания. Whirlpool, Tiger и RipeMD также являются отличным выбором. Ты не можешь ошибиться ни в одном из них.

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

кстати, я не совсем уверен, что с вашим алгоритмом смешивания нет слабости. Хотя выход каждого блока RSA предназначен для того, чтобы быть однородным с высокой лавиной и т. д., Я по-прежнему обеспокоен тем, что это может создать проблему для выбранного открытого текста или сравнительного анализа подобных сообщений.

3

шифрование RSA не является детерминированным: если вы следуете стандарт RSA, вы увидите, что некоторые случайные байты вводятся. Поэтому, если вы шифруете с RSA одно и то же сообщение дважды, есть вероятность, что вы не получите дважды один и тот же вывод.

кроме того, ваш "неопределенный Шаг 5", вероятно, будет слабым. Например, если вы определяете способ хэширования блока, а затем просто XOR блоков вместе, то A / / B и B / / A (для значений размера блока A и B) будет хешировать до того же значения; это столкновение bonanza.

академически было попробовано построение хэш-функций из теоретико-числовых структур (т. е. не сырой RSA, но повторное использование того же математического элемента); см. эта презентация от Ларса Кнудсена для некоторых деталей. Аналогично,функция хэша ECOH был представлен на конкурс SHA-3, используя эллиптические кривые в его ядре (но он был "сломан"). Основная надежда заключается в том, что безопасность хэш-функции может быть каким-то образом связана с основной теоретико-числовой проблемой, обеспечивая доказуемой безопасности. Однако на практике такие хэш-функции являются либо медленными, либо слабыми, либо обоими.

5

не думая слишком об этом, он Кажется как будто это было бы криптографически безопасно.

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

Итак, короче говоря: да, это кажется возможным и безопасным... но если нет действительно веская причина, я будет использовать стандартный HMAC, если вы хотите хэш с ключом.

0

Как правило, лучше всего использовать алгоритм, который является общедоступным и проходит через процесс обзора. Даже при том, что могут быть известные недостатки с такими алгоритмами, это, вероятно, лучше, чем неизвестные недостатки в домашнем алгоритме. Обратите внимание, что я не говорю, что предложенный алгоритм имеет недостатки; просто, даже если здесь дано большое количество ответов, говорящих, что это кажется хорошим, это не гарантирует, что это не так. Конечно, то же самое можно сказать и о алгоритмы как MD5, SHA, etc. Но, по крайней мере, с ними, большое количество людей подвергли их тщательному анализу.

помимо предыдущих" шаблонных " предупреждений против разработки собственных криптографических функций, предлагаемое решение может быть несколько дорогостоящим с точки зрения времени обработки. Шифрование RSA на большом документе может быть запретительным.

0