Онлайн-игра: быстрое не очень безопасное криптографическое хеширование / функция контрольной суммы в JavaScript?

Question

Мне не нужно, чтобы это было слишком безопасно. Даже md5, который, как правило, сломан, безопаснее, чем мне нужно (если столкновение не может быть найдено в течение 2 минут, оно должно быть на 100% нормально).

Мне это нужно для видеоигры, которую мы устроим на хакатоне в эти выходные. У нас есть сервер, который будет имитировать основные части игры, и нам нужно синхронизировать нескольких игроков (мы используем socket.io и nodejs в качестве сервера комет) и убедиться, что ни один игрок не изменяет, изменяя значения. Таким образом, контрольная сумма (если они отправят действительную контрольную сумму, которая будет сравниваться с той, которая была сгенерирована на сервере, у пользователя есть нужные данные).

Итак, пока контрольная сумма не слишком легко реверсизируется, все должно быть в порядке.

Кроме того, поскольку у меня нет большого опыта работы с онлайн-играми (хотя я некоторое время использовал сокеты в C, Java, Python и даже PHP), было бы здорово, если бы кто-то мог порекомендовать некоторые чтения по общим шаблонам последовало. Все, что я нашел, было документом, объясняющим, почему онлайн Age of Empires 2 вроде как засосал:)

Большое спасибо

Дополнительная разработка:

У каждого клиента есть переменные (объекты со свойствами и т. Д.). События происходят у клиента, и поэтому состояния меняются. В зависимости от состояний переменные меняются. Итак, клиент отправляет состояния и хэш переменных на сервер. Сервер принимает новые состояния от клиента (которые могут быть, например, «нажата стрелка вправо»), проверяет, являются ли они действительными, и затем генерирует новые значения для переменных. Проверяет, соответствует ли хэш тому, который отправил клиент. Если это не так, он отправляет сообщение синхронизации клиенту, давая ему новые значения в своих переменных. Затем сохраняет все это и отправляет обновления другим клиентам по общим переменным. (поскольку не все переменные видны другим клиентам)

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

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

Answer 1

Не доверяй клиенту. Используйте сервер в качестве центрального органа, но не для основных частей , а для всех частей . Реплицируйте как можно больше игрового состояния на стороне сервера и передавайте клиентам эти данные. Не занимайтесь обработкой / как можно меньше на стороне клиента. Независимо от того, какие значения клиенты изменяют, сервер отклоняет их.

Answer 2

Слишком много мыслей для комментария, поэтому оставьте ответ, который содержит столько же вопросов;

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

Если нет, но вы не можете использовать TCP, то может быть важнее синхронизировать сообщения, чем вы думаете, особенно в среде локальной сети; Вы используете термин «хакатон», но я понятия не имею, что это на самом деле означает ... но вы на самом деле смотрите на предотвращение злонамеренных / вредных действий других игроков, которые могут отправлять поддельные пакеты? (очень просто сделать по локальной сети, если используется UDP)

Если это так, вам нужно подумать не только о том, чтобы получить «безопасный» метод для обеспечения синхронизации; Вам также необходимо проверить источник всех сообщений, прежде чем что-либо делать с ними, потому что информация об «источнике» IP в UDP / IP практически бесполезна, если не знать, куда отправлять ответ. Вы не можете предполагать что-либо на основании исходного IP-адреса.

(То, что я имею в виду, это то, что из-за «TCP» -процедуры, основанной на «соединении», в отличие от изолированных дейтаграмм UDP / IP; UDP упрощает в закрытой среде, такой как вы описываете, отправлять вредные дейтаграммы это может нанести ущерб.)

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

Таким образом, каждое соединение клиент / сервер должно иметь общую, случайную соль, которая должна, как минимум, восстанавливаться каждый сеанс. Происходит хеширование, и сообщения отправляются с хэшированной «подписью» - сообщение хешируется солью. Когда получатель получает это сообщение / подпись, он принимает сообщение и выполняет такое же хеширование с солью, и его результат должен соответствовать отправленной подписи, или сообщение подделано.

Answer 3

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

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

Answer 4

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