Генерация вектора инициализации без хорошего источника случайности - PullRequest
3 голосов
/ 14 января 2011

Для плагина хранения пароля (написанного на C) для Rockbox мне нужно сгенерировать векторы инициализации.

Проблема в том, что у меня нет хорошего источника случайности.Функция random (), предоставляемая Rockbox, не является криптографической ГСЧ.И у меня почти нет источников случайности, к которым я могу получить доступ (никаких движений мыши, ... на IPod, работающем с Rockbox).

Ключ в настоящее время получен через PBKDF2 из предоставленного пользователем пароля и соли(который является постоянным префиксом + некоторые данные из random ()).Я думаю, что псевдослучайные данные должны быть достаточно хороши для соли с 10000 итерациями PBKDF2.

Однако, откуда взять вектор инициализации?Это нормально, если я возьму некоторые полуслучайные данные (время + случайный ()) и SHA, скажем, 10000 раз?Должен ли я взять arc4random с начальным числом, взятым из random ()?

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

Редактировать: Всего один пользователь (я, владелец IPod), алгоритм шифрования: AES-CBC 256 бит.Файл просто хранит список сайтов / учетных записей / паролей для различных сайтов.Он редко изменяется (всякий раз, когда я создаю новую учетную запись на веб-сайте), когда это происходит, новая соль и генерируется новый IV.

Ответы [ 3 ]

2 голосов
/ 15 января 2011

ОТЛИЧНЫЕ НОВОСТИ! Вектор инициализации не должен быть случайным, он просто должен быть разным для каждого шифрования. Таким образом, вы можете использовать имя пользователя в качестве соли. Если вы используете как имя пользователя, так и время, то злоумышленник не сможет обнаружить повторное использование пароля.

2 голосов
/ 17 января 2011

Вообще говоря, с CBC IV ДОЛЖЕН быть случайным и равномерным. «Неповторяющегося» недостаточно. Чтобы быть более точным, весь смысл CBC в том, чтобы избежать ситуации, когда один и тот же блок данных подается дважды в базовый блочный шифр. Следовательно, условие состоит в том, что если вы шифруете два сообщения одним и тем же ключом, то разница двух IV должна быть равномерно случайной. При использовании 128-битного блочного шифра, такого как AES, вероятность того, что один и тот же блок получен дважды, достаточно мала, чтобы им пренебрегать - при условии, что IV выбирается случайным образом с равномерной вероятностью по всему пространству 128-битных значений , Любая структура в выборе IV (например, повторное использование того же IV, использование счетчика или генератор случайных чисел низкого качества) увеличивает эту вероятность, поскольку вы шифруете данные, которые сами по себе имеют большую структуру.

В этом есть и яркая сторона: если вы никогда не используете один и тот же ключ дважды, то вы можете допустить фиксированный IV. Но это сильное «никогда».

"Неповторяющийся IV" - недостаточно хорошее свойство для CBC. Однако есть некоторые режимы шифрования, которые могут использовать неповторяющийся IV. В частности, обратите внимание на EAX и GCM . Хитрость в том, что эти режимы используют предоставленный IV в пользовательском PRNG, который использует ключ шифрования; это преобразует неповторяющуюся IV (например, счетчик или «случайное значение» низкого качества) в нечто, что с криптографической точки зрения выглядит достаточно случайным. Не пытайтесь создать свой собственный PRNG! Это тонкие вещи, и нет точного способа проверить качество результата.

2 голосов
/ 15 января 2011

IV не обязательно должен быть случайным, он просто должен быть уникальным для данной пары ключей и данных (при условии, что мы говорим о IV для CBC).

Так что random () должен подойти для этой цели.

...