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

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

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

Мои вопросы действительно относятся к этой «солевой» ценности:

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

encryption cryptography salt
person myermian    schedule 27.07.2010    source источник

Ответы (5)


arrow_upward
5
arrow_downward

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

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

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

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

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

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

arrow_upward
3
arrow_downward

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

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

person caf    schedule 30.07.2010

arrow_upward
1
arrow_downward

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

2) Хранится.

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

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

person Steven Sudit    schedule 27.07.2010
comment
См .: stackoverflow.com/questions/1120381/ - person Steven Sudit; 27.07.2010
comment
И: stackoverflow.com/questions/1111494/ - person Steven Sudit; 27.07.2010
comment
Размер хэша не зависит от размера пароля и соли. Например, SHA-1 всегда создает 160-битный хэш. - person Steven Sudit; 27.07.2010
comment
Хеширование - это не шифрование, потому что вы не можете (за исключением атак с использованием радужных таблиц на короткие строки) восстановить оригинал. - person Steven Sudit; 28.07.2010
comment
Если я не понимаю, OP спрашивает о генерации ключей шифрования из парольных фраз, а не о хешировании и хранении паролей. - person Nick Johnson; 28.07.2010
comment
@Nick: Это не столько то, что вы неправильно поняли, поскольку OP неправильно понял. Соль имеет отношение только к хешированию паролей, но не к шифрованию. Соленый хеш вполне может использоваться в качестве ключа шифрования, но солевая часть предназначена для защиты от радужных таблиц, а не для увеличения или улучшения ключа. - person Steven Sudit; 28.07.2010
comment
Я согласен; Полагаю, я проигнорировал бит соления, а не шифрование; вы и другие проигнорировали бит шифрования, а не засаливание. :) - person Nick Johnson; 28.07.2010
comment
@Nick: Да, мы оба здесь играем в догадки. Это популярное развлечение на этом сайте. Зеленая галочка рядом с моим ответом означает, что я выиграл этот раунд. - person Steven Sudit; 28.07.2010
comment
@Steven Sudit: На самом деле OP прав - соли имеют отношение к функциям деривации ключей, которые используются для генерации ключей шифрования. См., Например, PBKDF2: en.wikipedia.org/wiki/PBKDF2 - person caf; 30.07.2010
comment
@caf: Я перечитал вопрос, возможно, вы правы, но опять же, может, и нет. Проблема в том, что ОП либо не понимает проблем, либо не умеет их сообщать, поэтому нам всем остается только догадываться об их намерениях. Если спрашивающий достаточно сбит с толку, может не быть единственного правильного ответа. Сказав это, я скажу вам, почему я не думаю, что речь идет о PKKDF2. Во-первых, сама идея использования соли с хешами возникла еще до KDF и носит более общий характер. Это было частью процесса входа в систему Unix на протяжении десятилетий. Современные версии - person Steven Sudit; 30.07.2010
comment
Безопасность паролей на основе хешей включает в себя как использование криптографических хешей, так и усиление посредством многих раундов итераций, и это по-прежнему не зависит от KDF. KDF берет эти алгоритмы и применяет их для создания ключей. Однако цель состоит не только в том, чтобы сгенерировать более сильный ключ (хотя это, безусловно, один положительный эффект), но и в том, чтобы получить несколько ключей из одного и того же секретного ключа, не раскрывая его. Короче говоря, вы правы в том, что KDF включает в себя генерацию как соли, так и ключа, но я не уверен, что OP думал об этом, или на самом деле, о чем-то таком конкретном. - person Steven Sudit; 30.07.2010
comment
@Nick: Возможно, вы захотите прочитать, что предлагает кафе. Они предлагают правдоподобное, но, на мой взгляд, не совсем убедительное альтернативное объяснение, которое поддерживает нечто похожее на вашу интерпретацию. - person Steven Sudit; 30.07.2010
comment
@Steven Sudit: Что ж, это, конечно, правда, что мы не можем точно знать, что думает ОП - я использовал их упоминание о ключах шифрования именно так (и отвечая на ваш комментарий к @Nick, Salting имеет отношение только к хешированию паролей, а не к шифрованию. что, я думаю, было немного чрезмерно обобщенным, поскольку KDF применяют соление в контексте шифрования). - person caf; 30.07.2010
comment
@caf: Прочитав статью, на которую вы ссылаетесь, я перешел на en.wikipedia.org/wiki/Key_derivation_function. Вот что я нашел интересным: он идентифицирует этот алгоритм входа в систему Unix - crypt - как пример KDF. Но crypt используется для аутентификации, а не для шифрования. Конечно, значение, генерируемое KDF, можно использовать в качестве ключа шифрования, но я не нахожу никаких примеров. Не могли бы вы указать мне на один, пожалуйста? - person Steven Sudit; 30.07.2010
comment
Хорошо, я нашел несколько примеров. На этом этапе, я думаю, будет справедливо сказать, что то, о чем мы говорили, считается KDF, и что KDF генерируют что-то, что можно использовать для шифрования, но часто не используется. Короче говоря, мы оба были правы, как и Ник. - person Steven Sudit; 30.07.2010
comment
@Steven Sudit: PBKDF2 довольно стандартен для приложений шифрования на основе паролей - например, TrueCrypt использует его (см. truecrypt.org/docs/?s=header-key-derivation). См. Также шифрование на основе пароля, описанное в PKCS # 5: ftp.rsasecurity .com / pub / pkcs / pkcs-5v2 / pkcs5v2_1.pdf. - person caf; 30.07.2010
comment
@caf: На самом деле, я нашел кучу примеров внизу той первой страницы WP. - person Steven Sudit; 30.07.2010

arrow_upward
0
arrow_downward

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

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

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

В основном вот что происходит.

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

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

При входе:

  1. Пользователь отправляет пароль на сервер.
  2. Сервер извлекает сохраненный хэш и добавляет его к паролю.
  3. Сервер хеширует пароль и соль.
  4. Если окончательный хэш совпадает с хешем в базе данных, пользователь входит в систему.
person Community    schedule 27.07.2010
comment
2) Соли обычно хранятся вместе с хешами. Они предназначены только для защиты от радужных таблиц. - person Steven Sudit; 28.07.2010
comment
В качестве продолжения учтите, что атаке не требуется соль или пароль для входа в систему, а только хеш. - person Steven Sudit; 28.07.2010
comment
2) Я не совсем уверен, почему Википедия сказала, что они обычно хранятся отдельно для дополнительной безопасности ... Думаю, это один из тех случаев, когда Википедия ошибается. Кроме того ... Почему одного хеша будет достаточно? Сервер не будет принимать только хеш для входа в систему, ему потребуется пароль, который он затем может хешировать. - person EdoDodo; 28.07.2010
comment
Википедия ошибается во многом. В ответ на ваш вопрос рассмотрите эту схему: веб-сервер получает пароль в виде обычного текста по HTTPS и ищет соль пользователя. Он объединяет их и генерирует хеш. Затем он передает хэш на сервер приложений с каждым запросом. Сервер приложений сверяет его с базой данных. Преимущество состоит в том, что веб-серверу не нужно хранить пароль в виде обычного текста только для того, чтобы передавать его серверу приложений, а серверу приложений не нужно поддерживать состояние, хотя он и кэширует. Однако злоумышленник может поразить сервер приложений только с помощью хэша. - person Steven Sudit; 28.07.2010

arrow_upward
0
arrow_downward

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

Да, но...

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

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

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

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

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

ваше здоровье

Даниэль

person Daniel Gartmann    schedule 28.07.2010
comment
8 символов - это не 2 ^ 8 возможностей. Для истинных произвольных байтов 8 байтов составляют 2 ^ 64. Для обычных буквенных символов это 52 ^ 8. Это более чем 256 вариантов :-P. - person Borealid; 28.07.2010