Статус SHA3 и тестовые векторы PBKDF2-HMAC-SHA3

Поскольку SHA-3 кажется уже известной функцией (Кекчак как финалист NIST hash соревнование функций) У меня есть несколько вопросов, связанных с этой темой:

  1. На сайте NIST сообщается, что NIST закрыт из-за прекращения государственного финансирования. Есть ли шанс, что SHA-3 когда-нибудь будет окончательно принят?
  2. Библиотека BouncyCastle имеет реализацию SHA-3, результаты дайджеста аналогичны примерам, опубликованным в статья в Википедии (это я тестировал). Поскольку окончательный стандарт не утвержден, можно ли этому доверять? Википедия говорит, что это, вероятно, будет изменено, но как это может измениться, поскольку окончательный алгоритм, похоже, не подлежит изменению (иначе это будет другой алгоритм).
  3. Здесь кто-то заметил, что использование PBKDF2 с SHA -3 для усиления ключа и хеширования паролей следует избегать. Но я не могу понять, почему? (как это может дать злоумышленнику преимущество, если алгоритм небыстрый?)
  4. Я нигде не смог найти тестовые векторы для проверки моей реализации PBKDF2-HMAC-SHA3 в scala на основе Java API BouncyCastle. Я могу опубликовать свою тестовую спецификацию с некоторыми результатами. Но сначала кто-нибудь может опубликовать какие-либо тестовые векторы / спецификации?

Вот моя реализация в scala:

package my.crypto

import org.bouncycastle.crypto.digests.SHA3Digest
import org.bouncycastle.crypto.generators.PKCS5S2ParametersGenerator
import org.bouncycastle.crypto.PBEParametersGenerator
import org.bouncycastle.crypto.params.KeyParameter

object PBKDF2WithHmacSHA3 {

  def apply(password: String, salt: Array[Byte], iterations: Int = 65536, keyLen: Int = 256): Array[Byte] = {
    val generator = new PKCS5S2ParametersGenerator(new SHA3Digest(256))
    generator.init(
      PBEParametersGenerator.PKCS5PasswordToUTF8Bytes(password.toCharArray),
      salt,
      iterations
    )
    val key = generator.generateDerivedMacParameters(keyLen).asInstanceOf[KeyParameter]
    key.getKey
  }
}

Одна сомнительная вещь для меня - это new SHA3Digest(256), 256-битная длина в конструкторе, должна ли она быть такой же, как предоставленная длина ключа, или какая-то фиксированная, как у меня? Я решил использовать фиксированную длину, потому что можно использовать только некоторые фиксированные значения, и пользователь объектного API может указать любое значение в качестве параметра длины ключа, но большинство необычных значений приведет к возникновению исключения из конструктора SHA3Digest. Также значение по умолчанию равно 288 (когда длина ключа не указана), что выглядит странно.

Заранее спасибо!


person Oleg Stepura    schedule 04.10.2013    source источник
comment
Закрытие правительства США — это временная ситуация. Это не повлияет на окончательное решение чего-то вроде принятия нового безопасного алгоритма хеширования. В худшем случае он может быть отложен на неделю или две, если предположить, что он предназначен для принятия.   -  person Randall Schulz    schedule 05.10.2013
comment
(в качестве примечания: этим кем-то был я)   -  person CodesInChaos    schedule 05.10.2013
comment
Если вы сможете найти три (или более) библиотеки с реализациями Final Round Keccak и, возможно, помочь с кодированием интерфейса, если они на языках, которые вы знаете, я был бы рад сгенерировать и опубликовать тестовые векторы PBKDF2-HMAC-FinalRoundKeccak-xxx. . Тестовые векторы, которые я обычно использую, и некоторые образцы библиотек находятся на моем новом сайте github — обратите внимание на различные лицензии, конечно. Я прошу три, потому что, если все три согласны (и проходят тестовые векторы зависимостей, то есть известные выходы FRKeccak, я предполагаю, что это хорошо.   -  person Anti-weakpasswords    schedule 03.03.2014


Ответы (1)


  1. Отключение временное. Скорее всего, SHA-3 будет стандартизирован где-то в 2014 году.
  2. Нет, эти значения, вероятно, для Final Round Keccak, а не для SHA-3. Спецификации SHA-3 пока нет, и вполне вероятно, что SHA-3 будет изменен перед стандартизацией.

    => реализовать SHA-3 сейчас невозможно, можно реализовать только Keccak.

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

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

    SHA-1 и SHA-2 также хороши на аппаратном уровне, поэтому на практике разница невелика по сравнению с преимуществом других хэшей паролей по сравнению с PBKDF2-HMAC-SHA-x. Если вы заботитесь о безопасности, а не о соответствии стандарту, я рекомендую scrypt.

person CodesInChaos    schedule 05.10.2013
comment
Привет, @CodesInChaos. Спасибо за отличный ответ! Рад, что вы нашли свою цитату здесь =). - person Oleg Stepura; 05.10.2013
comment
После прочтения статьи в Википедии о scrypt кажется, что scrypt — лучший вариант. И статья частично объясняет то же самое, что и в № 3. И он также включен в BouncyCastle. Считаете ли вы, что это хорошо для использования в качестве функции вывода ключей для AES-256 с некоторой солью и некоторым iv? - person Oleg Stepura; 05.10.2013
comment
Другой вопрос: какие решения лучше использовать для хэширования и аутентификации сообщений — SHA-3 и HMAC-SHA-3 или SHA-256 и HMAC-SHA-256? Или, может быть, вы также можете порекомендовать что-то более сильное (поскольку я гораздо больше забочусь о безопасности, чем о соответствии стандарту)? - person Oleg Stepura; 05.10.2013
comment
1) scrypt - прекрасный выбор для этого. Одним из незначительных недостатков является то, что он может быть подвержен атакам по времени кэширования в тех случаях, когда злоумышленник знает соль. Вам также следует рассмотреть возможность использования собственного кода для этого, вы сможете использовать значительно более высокие коэффициенты работы. 2) Все они хороши как MAC. Даже HMAC-MD5 не сломался (все же не рекомендую). 3) SHA-3 в дуплексном режиме имеет то преимущество, что может шифровать и MAC одновременно. В качестве альтернативы вы можете рассмотреть режимы аутентификации, такие как AES-GCM или XSalsa20Poly1305. - person CodesInChaos; 06.10.2013