Цифровая подпись против HMAC с ключом через DH - PullRequest
Новая
       64

Цифровая подпись против HMAC с ключом через DH

3 голосов
/ 16 апреля 2011

Я пишу приложение, которое интенсивно использует криптологию. Как и большинство сетевых приложений, моя разделяет данные на различные типы сообщений (мгновенные сообщения, файловый блок, видеокадр и т. Д.), И каждое из них должно быть проверено на подлинность как на предмет защиты от подделки, так и на правильное происхождение. Пока я могу использовать ECDH для согласования общего секрета, который я уже использую для AES. Конечно, этот же общий секрет может быть использован позже.

Мой вопрос: В этом случае есть ли какое-либо дополнительное преимущество использования ECDSA для подписи каждого сообщения, а не просто использования общего секрета, установленного ECDH с HMAC?

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

Я понимаю, что в ECDSA (или DSA) обычно хэширует сообщение (M) с алгоритмом безопасного хеширования (в настоящее время я использую один из SHA-2) для создания H(M), затем шифрует H(M) используя закрытый ключ подписавшего. Это производит R и S целые числа (подпись). Затем M, R и S отправляются получателю, который уже владеет открытым ключом отправителя. H'(M) рассчитывается, а подпись проверяется с использованием R и S. BouncyCastle предоставляет ECDSASigner, который реализует это.

В HMAC требуется общий секрет, который у меня есть. Тогда:
HMAC(K, M) := H( f2(K) || H(f1(K) || M) ) (Спасибо за исправление, Paŭlo Ebermann. Подробности смотрите в его ответе.)

Итак, учитывая, что DH / ECDH безопасно согласовывает общий секрет, есть ли причина, по которой я не должен использовать HMAC?

Связанный: почему NSA определяет стандартный алгоритм для DSA, а не MAC? Только потому, что это может быть SHA-2 + AES?

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

Спасибо за вашу помощь!

1 Ответ

4 голосов
/ 16 апреля 2011

Одним из недостатков DSA является то, что вам нужны довольно хорошие случайные байты для вашей подписи.Это даже тот случай, когда с помощью неверного случайного источника ваш личный ключ может быть восстановлен по подписи.Для MAC вы должны подписать много сообщений, поэтому вам нужно много случайных чисел.Если у вас нет аппаратного обеспечения, производящего их, у вас закончится энтропия.

HMAC не требует никаких случайных чисел (это является детерминированным).

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

О «правильных ошибках»: Ваше описание HMAC не совсем верно - здесь нет «расшифровки».Это больше похоже на:

У вас есть сообщение M, хеш-функция H и общий секрет K.Добавьте две открытые функции f1 и f2 (это простое заполнение XOR +).Тогда 

HMAC(K, M) := H( f2(K) || H(f1(K) || M) )

с || - простая конкатенация.Отправитель и получатель выполняют одинаковые вычисления, отправитель отправляет свой с сообщением, а затем получатель сравнивает свой результат с отправленным.(Удостоверьтесь, что вы проводите сравнение таким образом, чтобы не допустить атаки по времени, т.е. сравнивайте все, даже если вы уже обнаружили, что оно не соответствует.)

Точное определение HMAC приведено в RFC 2104, который также содержит некоторые уточняющие цифры.

Об этом вопросе:

Связанный: почему NSA задает стандартный алгоритм для DSA, а не MAC?

Я не совсем уверен, но вот одна идея:

В списке ссылок упоминается " Режим счетчика Галуа " для TLS (RFC 5288) и SSH (RFC 5647) , и это, как говорят, защищает как конфиденциальность, так и целостность в одном.Таким образом, отдельный MAC больше не нужен.(Я впервые читаю это, поэтому не могу судить об этом прямо сейчас.)

...