Хеширование с солью

	Комментарий модератора
	Тема была вынесена из обсуждения Шутки о компьютерщиках и компьютерах (2)

Читал Документ "Политика конфиденциальности Google Chrome" и обнаружил это

Миниатюры

 

0

просто я если не уверен в чем-то более чем на 50%, не пишу вообще

0

Сообщение от DenNik а при чем соль? не пойму

Допустим мы имеем дело с WiFi роутером, для доступа к которому нужно иметь пароль. Однако, число возможных паролей не так велико как может показаться на первый взгляд. У 90 процентов пользователей это осмысленные слова. Число которых весьма невелико. К примеру хороший писатель это 10000 слов словарного запаса, современный офисный работник наверное не более 2000. Понятно что многие усложняют пароль добавляя цифры, но опять же, если поискать в интернете словари паролей, то становится понятным, что очень многим ума хватает не более чем на pass12345 или какой нибудь vasya_pupkin_666. При кажущейся сложности данных паролей, вероятность их нахождения весьма велика. Именно поэтому в функцию хеширования было введено такое поняти как "соль" Например всё в тех же роутерах в качестве соли выступает название точки доступа. Т.е. по сути это всё то же продолжение пароля, однако поскольку оно выдрано из контекста основного пароля, то позволяет увеличить число возможных вариантов перебора. К тому же становится весьма затратным проводить атаку по предварительно рассчитаным таблицам.

Т.е. если условно можно заранее рассчитать хеши всех паролей минимально допустимой длинны (8 знаков). И по этой таблице в течении нескольких секунд находить соответствие, то с наличием соли составление такой таблицы становится весьма затруднительным. Ибо она уже не ограничивается миллиардами комбинаций. Т.е. Пароль pass1234 соль: ASUS_kv152 это один хеш, а Пароль pass1234 соль: Network это уже другой хеш.

Сообщение от DenNik и что-то я не пойму тогда, зачем шифровать в один конец?

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

2

Сообщение от NeoMatrix У Боба имеется ключ B

Сообщение от NeoMatrix При получении криптограммы Алисы Боб применяет обратную функцию

ключи А и В должны быть как-то взаимосвязаны? Алисе и Бобу нужно заранее обменяться ключами?

0

Сообщение от DenNik Алисе и Бобу нужно заранее обменяться ключами?

Да. В общем виде это происходит так:
Боб генерирует пару взаимосвязанных ключей, один из которых предназначен для зашифровывания сообщения и получения таким образом криптограммы, а второй для расшифровки криптограммы в сообщение.
Первый ключ он отсылает Алисе, а второй оставляет себе.
Алиса так же генерирует аналогичную пару ключей и отсылает Бобу ключ для создания криптограмм, а второй так же оставляет себе.
Теперь для того, чтобы Алиса написала Бобу послание она применяет ключ, полученный от Боба. Боб для посланий Алисе применяет ключ полученный от Алисы. Получаемые криптограммы каждый расшифровывает собственноручно сгенерированным ключом, первая половина пары которого была передана собеседнику.
Таким образом, получается, что каждый из абонентов сети имеет по паре ключей, для шифрования-расшифрования посланий к_конкретному/от_конкретного собеседника,
То есть, если в сети существует 10 абонентов, то каждый хранит по 9 пар ключей.
Если более "на пальцах", то
1. У нас имеется сеть из четырёх абонентов: Алиса, Боб, Крис, Даниель.
2. Алиса хранит у себя ключи Б\Б', К\К', Д\Д'
3. Боб хранит ключи А\А', К\К', Д\Д'
4. Крис хранит ключи А\А', Б\Б', Д\Д'
5. Даниель хранит ключи А\А', Б\Б', К\К'
Для зашифровывания используется первым ключом, а для расшифровывания - вторым. То есть, когда Крис пишет Даниелю, он использует ключ Д, а когда Даниель получает это письмо, он использует ключ К'. то есть в письме должны существовать теги "от кого" и "кому". для правильного применения ключей.
Это было описание алгоритма децентрализованной системы обмена сообщениями.

В современной централизованной системе обмена сообщениями применяется другой алгоритм, основанный на этой же схеме, но подразумевающий использование сервера сообщений (арбитра):
Каждый из участников сети хранит только одну пару ключей, а сервер хранит ключи всех участников, плюс собственный.
Собственный ключ привязан к конкретной машине (серверу).
Обмен криптограммами происходит через сервер сообщений и напрямую между участниками невозможен.
Для того, чтобы получить возможность вступить в сеть обмена сообщениями новый абонент должен зарегистрироваться на сервере.
Во время регистрации сервер генерирует новую пару ключей, первую половину которой отсылает новому абоненту. В принципе, новую пару ключей сервер может и не генерировать, просто выслав абоненту уже однажды сгенерированный в самом начале S. В ответ абонент генерирует свою пару ключей А\А', первую половину из которого отсылает серверу и сервер хранит его. В итоге абонент хранит у себя пару S\А'.
Сервер при получении от абонента криптограммы, предназначенной для другого абонента, расшифровывает полученное от абонента1 сообщение, сразу же зашифровывает своим ключом и отсылает абоненту2.
В целях безопасности, как я уже отмечал выше, его собственный ключ привязан к определённой машине, на которой он может выполняться - к серверу. То есть выполнить операцию по перешифровке полученной сервером криптограммы в отправляемую другому абоненту на другом хосте без коллизий уже невозможно. Кроме того, для исключения возможности нахождения перешифровываемого сообщения в открытом виде на сервере применяется более сложный алгоритм: сначала полученная криптограмма зашифровается ключом получателя (либо своим для получателя), а потом расшифровается ключом отправителя.
Таким образом, никто, кроме отправителя и получателя, не может видеть открытого содержимого сообщения.

0

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

0

Сообщение от DenNik слабое (или неудобное, если можно так сказать) место всей этой кутерьмы - хренова туча ключей

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

0