Шифрование: Как превратить 8-символьную строку в 128-битный ключ, 256-битный ключ и т. Д.?

Question

Я пытался исследовать это, но некоторые вопросы остались без ответа. Я пытался выяснить, как 8-символьный пароль превращается в высокобитный ключ шифрования. Во время моего исследования я нашел статьи, в которых говорилось бы о соляной ценности.

Предположим, что вы можете получить все 256 символов для игры, тогда 8-значный пароль будет иметь длину 64 бита. Итак, оставшиеся 64 бита - это просто солт-значение. И, поправьте меня, если я ошибаюсь, но это сделано для того, чтобы, если кто-то собирался попробовать ALL возможные значения (грубая сила), ему пришлось бы попробовать все 128-битные, так как даже соль неизвестна.

Мои вопросы действительно относятся к этому значению «соли»:

1. Когда кто-то подает заявку, жестко ли в ней указывается значение соли? И если да, то не может ли он быть получен путем обратного проектирования исполняемого файла?
2. Если соль генерируется случайным образом, тогда я предполагаю, что у нее должен быть способ дублировать ее. Итак, не та ли функция, которая возвращает случайную соль, способную к обратному проектированию, чтобы заставить ее дублировать себя, чтобы получить значение соли?
3. Это может выходить за рамки, но если солт-значение генерируется на стороне сервера (отношения клиент / сервер), тогда не нужно будет делиться им с клиентом, чтобы они могли расшифровать данные, отправленные сервер? И, если он отправляется клиенту, не может ли он быть перехвачен, что делает его бесполезным?
4. Есть ли какой-то другой метод, который используется помимо этого значения соли, который может превратить 8-символьную строку в надежный ключ шифрования?

Answer 1

Как обычно в вопросах, связанных с безопасностью, этот ответ будет длинным.

Сначала простой ответ.
В: Как превратить 8-символьную строку в 128-бит ключ?
A: Нет.

Это правдивый ответ.Теперь одно, более соответствующее тому, что вы спрашиваете:
A: Создайте случайное 64-битное значение и сохраните его с паролем в базе данных.Теперь пароль - половина ключа, а случайное значение - другая половина.

Это ложь.Вот что вы на самом деле делаете:
A: Хешируйте пароль вместе со случайной солью, используя метод, производящий 128-битный или более длинный вывод.Используйте 128 бит этого ключа.Храните соль.

Теперь, чтобы ответить на ваши вопросы о соли.Во-первых, цель соли не в том, чтобы удлинить ключи шифрования.Это сделано для того, чтобы люди не строили радужных таблиц - отображения из хэшированных в не хэшированные формы.Чтобы увидеть, что ваше шифрование не сильнее, просто представьте, что злоумышленник знает ваш алгоритм расширения ключа.Теперь, вместо того, чтобы угадывать 128-битные ключи, он просто угадывает ваш 64-битный пароль и затем использует тот же алгоритм.Вуаля.Если соль неизвестна атакующему, да, вы немного выиграли, но у них уже должны быть ваши шифротексты, чтобы атаковать их, и соль должна храниться на равнине вместе с зашифрованным текстом.Так что это маловероятный сценарий.

1. Соль случайна для каждого ключа шифрования.
2. Случайно означает случайный.Если вы недостаточно случайны, когда используете криптографический алгоритм, предполагающий непредсказуемый материал, вы уязвимы.Вот для чего /dev/random - пул энтропии системы очень хорош.Если вы беспокоитесь, получите более качественную аппаратную ГСЧ.
3. Да, если вы солили ключ, кому-то нужна соль для расшифровки зашифрованных вами данных с использованием хешированного значения соленого ключа.Нет, отправка соли не обязательно ставит под угрозу ваши данные;отправляйте соль только тому, кто подтвердил, что у него уже есть пароль, но он хранится в вашей базе данных рядом с зашифрованным текстом.Как упомянуто выше, кому-то нужна соль и зашифрованный текст для атаки.Опять же, целью соли является , а не , чтобы повысить силу шифрования, это только для того, чтобы предотвратить атаки до вычислений на ваши хэши.
4. Существуют методы расширения ключа.Но, в сущности, ваша защита настолько сильна, насколько слабее ее соединение, поэтому для обеспечения 100% неразрушимого шифрования вам понадобится одноразовая клавиатура (действительно случайный ключ, если данные должны быть зашифрованы).).В реальном мире обычно хешируют пароль и соль для получения непредсказуемого более длинного ключевого материала.

Answer 2

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

Причина, по которой ключ произведенФункция использования соли заключается в увеличении коэффициента работы для любого злоумышленника.Если соль не использовалась, то данный пароль будет производить только один единственный ключ.Это означает, что злоумышленник может легко создать словарь ключей - один ключ для каждого слова в своем словаре.С другой стороны, если используется 64-битная соль, то каждый пароль может генерировать ~ 2 ** 64 различных возможных ключа, что увеличивает размер словаря на тот же коэффициент.По сути, это делает преждевременным создание такого словаря.Вместо этого злоумышленник должен подождать, пока он не увидит значение соли, а затем начать генерировать ключи для проверки.Поскольку функция получения ключа является вычислительно дорогой, она медленная, и он не сможет пройти через свой словарь в разумные сроки.

Answer 3

1) Каждый пароль добавляется по-разному, а соль сохраняется с хешем.

2) Хранится.

3) Нет, клиент никогда ничего не расшифровывает. Он отправляет пароль, который сервер солит, хэширует и сравнивает.

4) Да, я добавлю несколько ссылок.

Answer 4

... Есть ли какой-то другой метод, который используется помимо этого значения соли, который может превратить 8-символьную строку в надежный ключ шифрования?

ДА, но ...

Вы можете вычислить хеш этой 8-символьной строки:

Например, если вам нужен 256-битный ключ:

key-256bit = hash (8-символьная строка) // использовать SHA-256 - очень безопасный ключ-128bit = hash (8-символьная строка) // использовать MD5, более не считающийся безопасным

"в надежный ключ шифрования?"о сильном .... зависит от того, насколько сильным он вам нужен, потому что если вы используете только 8-символьную строку, это означает, что вы можете создать только 2 ^ 8 = 256 различных хеш-значений, и это простая задача для грубой силы !!

вывод: соль будет иметь большое значение!

ура

Даниэль

Answer 5

1. Соли, как правило, не жестко закодированы, но они генерируются случайным образом, обычно на стороне сервера, и никогда не передаются пользователю.

2. Соль будет храниться в базе данных, отдельно от паролей. Идея состоит в том, что даже если украдена база данных хэшей паролей, будет очень трудно получить реальные пароли (вам нужно будет попробовать много комбинаций) без солей. Соли будут генерироваться случайным образом и различаться для каждого пользователя, поэтому, даже если вы найдете это для одного, вам все равно нужно будет найти все остальные.

3. Соль никогда не отправляется, потому что клиент никогда ничего не расшифровывает. Клиент отправляет пароль на сервер, сервер добавляет соль (которая генерируется случайным образом и сохраняется для каждого пользователя, а пользователь никогда не узнает его).

Так что в основном это то, что происходит.

При регистрации:

1. Пользователь отправляет пароль на сервер.
2. Сервер добавляет случайную соль к паролю, а затем хэширует его.
3. Соль и окончательный хэш хранятся в отдельных таблицах.

при входе в систему:

1. Пользователь отправляет пароль на сервер.
2. Сервер извлекает сохраненный хеш и добавляет его к паролю.
3. Сервер хеширует пароль и соль.
4. Если последний хеш совпадает с хешем в базе данных, пользователь регистрируется в.