Получение ключа с использованием libgcrypt в C

Question

Я разрабатываю простое программное обеспечение, которое выполняет шифрование файлов aes256-cbc. Это программное обеспечение разработано на GNU/Linux с использованием libgcrypt-1.5.0.

Я хочу использовать вышеуказанную функцию с GCRY_KDF_PBKDF2 как algo а также SHA512 как субальго.

gcry_kdf_derive( const void *passphrase, size_t passphraselen, int algo, int subalgo,
                 const void *salt, size_t saltlen, unsigned long iterations, 
                 size_t keysize, void *keybuffer )

Эта функция извлекает ключ из passphrase, keysize дает запрашиваемый размер ключей в октетах. keybuffer является предоставленным вызывающим буфером, заполненным в случае успеха полученным ключом. Входная фраза взята из passphrase который является произвольным буфером памяти октетов passphraselen. algo определяет алгоритм KDF для использования; увидеть ниже. subalgo определяет алгоритм, используемый внутри алгоритмами KDF; обычно это хеш-алгоритм, но некоторые алгоритмы KDF могут использовать его по-разному. salt является солью длинных сальтенных октетов, как требуется большинству алгоритмов KDF. iterations является положительным целочисленным параметром для большинства KDF.

Я не понимаю три вещи о том, как использовать эту функцию:

1. salt должен генерироваться случайным образом, поэтому он должен быть не зашифрован в выходной файл, не так ли? (IV-шифротекста-ОСВ-MAC),
2. saltlen имеет правильное значение "крипто" или я могу выбрать то, что я предпочитаю? Нравится 10,20,30...
3. размер ключа (в данном случае) должен быть 512, верно?

Answer 1

1) соль должна генерироваться случайным образом, поэтому она не должна быть зашифрована в выходной файл, не так ли? (IV-шифротекста-ОСВ-MAC),

Правильно, хотя более логичной формой будет SALT-IV-CIPHERTEXT-MAC в каком-то формате контейнера. Это будет порядок, в котором другой стороне понадобятся компоненты для

1. рассчитать ключи
2. проверить данные
3. расшифровать данные

2) Saltlen имеет правильное значение "crypto" или я могу выбрать то, что я предпочитаю? Нравится 10,20,30...

Минимальный минимум (для системы с высокой степенью защиты) составляет 64 бита или 8 байт, но, поскольку вы используете высокопроизводительные крипто-примитивы, почему бы не использовать 256-битную безопасную случайную выборку, соответствующую вашему размеру ключа.

3) размер ключа (в данном случае) должен быть 512, верно?

Это верно, размер ключа в битах должен быть 512. API ожидает, что аргумент KEYSIZE будет в октетах, поэтому он будет 64 октета. Кажется, вы хотите выполнить подпись / проверку MAC. Для этого требуется отдельный ключ от ключа, используемого для шифрования / дешифрования. Таким образом, вам нужны два 256-битных ключа, что, к счастью, совпадает с выводом алгоритма SHA-512. Я сказал "к счастью", потому что вы действительно не хотите, чтобы PBKDF2 вычислял другой блок - он снова прошел бы через все итерации.

Значение IV лучше всего рассчитывать отдельно и ставить перед зашифрованным текстом. Вы должны включить значение IV в расчет MAC (иначе первый блок простого текста не будет проверен). IV должен быть случайным блоком данных, чтобы 128 битов или 16 байтов безопасных случайных данных для AES.

Answer 2

1) Значения соли не являются секретными и могут храниться вместе с зашифрованными данными. Все они перемешивают зашифрованные значения, так что пароль "cat", использующий GCRY_KDF_PBKDF2 и SHA512 для шифрования слова "the", не всегда создает зашифрованный текст "86c8z385a33146b59d" или что-то еще. Это защищает от атак с использованием радужных таблиц. Вы можете поместить его в зашифрованный файл, но он более полезен в качестве метаданных.

2) Я не думаю, что это имеет значение. Что вы хотите. Хотя при цене жестких дисков умножение размера радуги на 8 не смешно. Таким образом, вы можете захотеть больше, чем один байт.

3) Да, так как вы используете SHA-512, ваш размер ключа 512.

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