Самоизменяющийся алгоритм хеширования

Question

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

Answer 1

Я предлагаю просто использовать SSL. Он спроектирован так, чтобы быть достаточно устойчивым к атакам «человек посередине», что, как я полагаю, является вашей задачей.

Или, может быть, Kerberos.

Не кодируйте алгоритмы шифрования самостоятельно.

Answer 2

Я бы порекомендовал SSL вместо реализации какого-либо алгоритма шифрования самостоятельно (он будет сломан, если данные, которые вы пытаетесь защитить, достаточно важны!). SSL хорошо протестирован. с SSL вы можете использовать сертификаты вместо логинов / паролей. SSL предотвращает повторное воспроизведение и атаки «посредник» (вначале он использует рукопожатие, чтобы убедиться, что новый ключ сеанса используется для каждого соединения и что обе стороны являются теми, кем они себя считают).

Еще одна интересная вещь, которая приходит на ум - это SecurID RSA. он предоставляет аппаратный ключ, который меняется каждые 60 секунд: http://www.rsa.com/node.aspx?id=1156

Answer 3

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

Например, допустим, что ваши ключи имеют ширину 8 элементов (где элемент может быть байтом, или 32-битным словом, или чем-либо еще), и мы будем обозначать ключи, которые вы используете для шифрования любого данного блока данных, как Kn, где 'n' - блок данных, зашифрованный этим ключом. Мы будем индексировать элементы ключа, говоря Kn [0] для 1-го элемента, до Kn [7] для 8-го. Мы также назовем этот блок данных Dn. Тогда открытый текст Dn будет включать в себя Kn + 1 [0], Kn + 2 [1], Kn + 3 [2], ..., Kn + 8 [7]. Если вам удалось расшифровать Dn-7 .. Dn, то вы полностью восстановите Kn + 1, так что вы сможете расшифровать следующий блок данных и так далее. Вам нужно получить открытый текст для нескольких последовательных блоков, прежде чем вы сможете надежно расшифровать остальные данные, хотя получение открытого текста для любого данного блока облегчит атаки на остальные ключи.

Первоначальная настройка является более сложной проблемой. SSL был бы хорошим способом распределения K0, K1 [1..7], K2 [2..7], ..., K7 [7].

Я не профессиональный криптограф, поэтому я не совсем уверен, насколько это безопасно. Этот алгоритм предлагается вам КАК ЕСТЬ, без каких-либо гарантий.

Answer 4

Это, безусловно, возможно - например, японский Фиолетовый шифр во время Второй мировой войны сделал это. Хотя такой шифр, безусловно, может быть сложным, он также может быть взломан (Пурпур был).

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