2014-11-06 2 views
0

Я пишу свою первую систему входа в игру. Решил на СРП и успешно реализовал это взаимодействие. Теперь клиент и сервер имеют одинаковые ключи сеанса. Как их использовать?Пример использования ключей сеанса SRP

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

SRP обменивает ключ сеанса в процессе аутентификации. Этот ключ может быть использован для шифрования пользователя для входа в сеанс ...

http://srp.stanford.edu/advantages.html

Установленный ключ сеанса «S» может использоваться для шифрования дальнейшей связи между клиентом и сервером.

http://connect2id.com/products/nimbus-srp

Какие варианты здесь, и какие хорошие варианты? AES?

Спасибо!

+0

Ваши кавычки не соответствуют ссылкам, которые вы предоставлена. Текст нигде не встречается в той же формулировке. Пожалуйста, исправьте это. Также без конкретной проблемы, связанной с программированием, это, по-видимому, лучше подходит для [Crypto.SE] (http://crypto.stackexchange.com/). –

+0

Исправлена ​​цитата из Стэнфорда, другая - в порядке. – douggard

ответ

1

Я бы не Рекомендую вам использовать SRP для входа в систему, а затем для шифрования передачи данных самостоятельно с помощью общего сеансового ключа SRP. Было бы безопаснее и проще использовать обычный TSL, используя готовые библиотеки и хорошо документированные конфигурации (например, самоподписанные сертификаты). Затем в верхней части зашифрованного подключения войдите пользователь с SRP в качестве пароля, и вы закончили.

Если вы действительно хотите сделать то, что вы предлагаете, то алгоритм симметричного шифрования, который вы выберете, будет основан на служебных служебных стихах известных сильных/слабых сторон алгоритма. AES очень сильный, но очень дорогой. Если вы шифровали файлы на диске, которые хотите сохранить в безопасности, вы хотите использовать очень сильный шифр. Игровой трафик редко нуждается в защите от расширенной автономной атаки; как правило, результаты игры являются общедоступными, а трассировка игры через дешифрованные часы после окончания игры не имеет значения. В этом случае вы можете использовать очень дешевый stream cypher для защиты трафика.

В качестве примера вы можете рассмотреть ISAAC, который так быстр и дешев, он также используется в качестве генератора случайных чисел. Это означает, что вы можете найти реализации практически в каждом языке include browser javascript. Вы использовали бы начальное состояние генератора Исаака как на клиенте, так и на сервере, используя общий ключ SRP. Затем для каждого 32 бита данных, которые вы хотите передать, вы берете следующий Исаак 32-битный псевдослучайный и XOR данные и отправляете их. На другом конце вы XOR со следующим 32-разрядным Исааком псевдослучайным образом, чтобы восстановить исходные данные. Любой, кто отслеживает пакеты, не имеет семян Исаака, которые поступают из общего ключа SRP, поэтому они не могут декодировать скремблированные данные. Исааку требуется 256 х 32-битных слов в качестве исходного состояния, а ключ SRP будет состоять только из 8 х 32-битных слов (если вы использовали SHA256 в качестве алгоритма хеширования SRP). Это означает, что вам нужно либо растянуть ключ SRP, либо повторить его 32 раза, чтобы сделать семя Исаака. Ключевой алгоритм растягивания, такой как PBKDF2, может быть применен для расширения ключа SRP для заполнения начальной таблицы Isaac. Это должно быть «достаточно хорошим» для защиты игры от «реального времени». (Редактировать: Рекурсивно хэшировать ключ 32 раза, чтобы генерировать семя isaac - это еще одна идея.)

Еще раз я бы не посоветовал вышеуказанный подход; Я бы рекомендовал использовать стандартные TLS/HTTPS для шифрования соединений, а затем использовать SRP в качестве пароля для проверки подлинности только для пользователя и отправки всего трафика по первоначальному зашифрованному соединению.

(Edit Существует задание на введение в криптографию курса, чтобы сломать Vigenère cipher как тот выше, используя вероятность каждой буквы появляется в достаточно большом теле зашифрованного текста. Таким образом, вы должны сжать данные вы перед тем как зашифровать его. Однако действительно, что это говорит нам, «никогда не пишите свое собственное шифрование», поскольку вы, возможно, пропустили возможную атаку, используйте только профессионально подобранный код, такой как TSL.)

Смежные вопросы