SHA-3 статус и PBKDF2-HMAC-SHA-3 тестовые векторы

Question

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

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

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

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 (если не указана длина ключа), что выглядит странно.

Заранее благодарен!

Answer 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.