Для отправки паролей по проводам, что более безопасно: Diffie-Helman / AES или RSA? (Меня беспокоит, что AES не скрывает длину пароля) - PullRequest
5 голосов
/ 19 января 2010

Мне дали совет, к которому я отношусь с подозрением, поэтому я ищу здесь поддержку, чтобы вернуться и оспорить совет.

Мне посоветовали использовать Диффи-Хелмана, чтобы обе стороны согласовали секретный ключ, использовать секретный ключ для генерации ключа AES, а затем использовать AES для шифрования / дешифрования передаваемых паролей. Очень похоже на пример кода здесь

При использовании этой схемы длина зашифрованного пароля равна длине незашифрованного пароля. Должен ли я беспокоиться об этом?

Раньше я использовал RSA, шифруя пароли открытым ключом получателя. Это привело к зашифрованной длине 256 независимо от длины пароля. Разве это не лучше?

Ответы [ 3 ]

3 голосов
/ 19 января 2010

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

Второе: ИМХО, вы никогда не должны отправлять пароли по проводам для аутентификации (я не знаю ни одного протокола аутентификации, которыйвключая ужасно небезопасный протокол NTLMv1. [1]Предостережение: я не криптограф - я считаю, что в том, что я здесь описываю, есть серьезные недостатки):

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

Другими словами, пусть сервер отправит клиенту солт-значение, добавит солт к паролю, вычислит OWF значения пароль + соль и отправит результат OWF на сервер.На сервере добавьте соль к паролю, а также выполните расчет OWF.Если результаты совпадают, пароль действителен, если нет, то он недействителен.

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

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

3 голосов
/ 19 января 2010

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

Обратите внимание, что если вы используете Диффи-Хеллмана, вам все равно нужно аутентифицировать отправленные параметры, что вам, вероятно, нужно сделать с RSA.

Альтернативыявляются:

  1. Используйте RSA для обмена зашифрованным секретным ключом, который затем используется для шифрования ваших данных.
  2. Используйте Диффи-Хеллмана для обмена секретным ключом и затем используйте RSA для подписи значенийотправлено для проверки подлинности транзакции.

Если вы сделаете все это, вам также придется беспокоиться о том, были ли переиграны обмены, чтобы заставить вас повторно использовать ключи и т. д.

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

Предложите вам использовать SSL / TLS для обмена, если вам нужно передавать много данных.PGP / PKCS # 7, если вам просто нужно отправить одно сообщение.

1 голос
/ 31 марта 2010

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

...