Войти
ПрограммированиеФорумСеть

Как защитить пакеты от изменения? какие чексуммы нужны?

Страницы: 1 2 3 4 Следующая »
#0
8:05, 31 янв. 2018

Допустим цель - текстовые сообщения, чат. Не дать man-in-middle изменить их. Сообщения нужно посылать по незащищенному соединению.

Допустим у сервера и клиента есть общий секретный - salt, который передаётся на сервер от клиента по RSA, во время установки соединения, дальше соединение незащищенное.

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

Какая должна быть длина соли? 4, 8, 16 байт?

Нужно ли генерировать соль крипто-генератором, или подойдёт обычный?

1) Будет ли достаточным использование CRC32(salt + packetData)? - я понимаю что это типа не хеш, но в связке с солью, разве можно вычислить соль в разумные сроки (1 неделя)? хотелось бы именно этот вариант, просто соль подлиннее сделать и всё?
2) MD5(salt + packetData) - 16 байт, более менее приемлемо, но уже многовато, может можно обрезать?
3) SHA1(salt + packetData) - не хочется использовать подобное, ведь это дофига байт надо добавлять в конец пакета.

В общем что обычно используют для подобной защиты пакетов от изменения? Или такое вообще уже не используют?

Нужно ли вообще игровой чат защищать каким бы то ни было образом? хоть хешсуммой, хоть криптографией? Тем более что по законам вроде заморочки с шифрованными чатами.

-—————

PS: можно ли использовать подход с чексуммами не только для чата, но и вообще для лобби сервера? где можно покупать боксы, открывать боксы, может даже удалять вещи из инвентаря? или тут обязательно нужно что то типа AES?

PS2: очень плохо разбираюсь во всей этой порнокриптографии.


#1
8:42, 31 янв. 2018

Что мешает сделать так, как в банкоматах? По RSA инициируется соединение, передается DES-ключ, потом DESом шифруется весь сеанс, практически бесплатно.
Криптостойкость DESа невелика, но на несколько часов можно рассчитывать, а потом сгенерировать новый ключ. В банкоматах максимальная длина сеанса то ли 10, то ли 15 минут, за столько DES не вскрывается.

#2
8:54, 31 янв. 2018

Шифруй всё.
1. Клиент устанавливает соединение с сервером.
2. Сервер и клиент меняются ключами RSA.
3. Оба передают свои ключи для AES при помощи RSA.
4. Дальше всё шифруется AESом.
5. Время от времени ключи для AES меняются. Передаются при помощи RSA.

Еще можно перед шифрованием AES сжимать трафик. И вместо RSA лучше взять эллиптические кривые.

#3
9:10, 31 янв. 2018

poly1305.  И вообще взять нормальную библиотеку типа libsodium, в которой всё уже продумано.

#4
9:31, 31 янв. 2018

youtube
> 5. Время от времени ключи для AES меняются. Передаются при помощи RSA.
Стоит ли таким заморачиваться? тем более что AES считается безопасным.

youtube
> Шифруй всё.
Проблема в том, что по законам РФ службы имеют права потребовать ключ шифрования для шифрованного трафика, в котором присутствуют текстовые сообщения пользователей. Я не совсем понимаю, что от меня требуется. Достаточно ли будет просто хранить секретные RSA ключи?, а AES ключ передавать внутри RSA, я им дам секретный RSA ключ, пускай сами достают из первого сообщения AES ключ? или я должен хранить еще и AES ключи?

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

Я вообще не понимаю как это всё делается, я должен куда то идти, где то регистрировать свою игру, разве я не могу просто сделать игру, залить её на стим директ и всё? Если я использую в клиенте RSA + AES я должен куда то докладывать, чтобы мне разрешили это сделать или как?

youtube
> И вместо RSA лучше взять эллиптические кривые.
А просто RSA 2048 будет не достаточно? не хочу сейчас заморачиваться с чем то не знакомым.

#5
9:49, 31 янв. 2018

kipar
> poly1305
Первый раз слышу, его используют для игровых чатов?

Его можно использовать для любых пакетов? не только текстовые сообщения? Допустим мне не нужно шифровать трафик, но нужно обеспечить его целостность, можно использовать poly1305 хеш в конце каждого пакета? он быстрее чем просто использовать AES?

#6
9:53, 31 янв. 2018

gamedeveloper01
> тем более что AES считается безопасным.
Нет такого понятия "безопасный". Есть криптостойкость, измеряющаяся в сроках вскрытия.

В игровых чатах разве есть что прятать? Зачем их вообще защищать?

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

#7
9:54, 31 янв. 2018

Zab
> В игровых чатах разве есть что прятать? Зачем их вообще защищать?
Так он и не собирался их защищать. Он хотел подписать.

#8
9:59, 31 янв. 2018

Zab
> В игровых чатах разве есть что прятать? Зачем их вообще защищать?
Вообще нечего прятать, допустим у меня mmo соединение с сервером, которое надо защитить - мне даже не нужно шифровать трафик, там нет ничего секретного, мне просто достаточно защитить пакеты от подмены и всё. Разве не желательно сообщения чата тоже защитить от подмены? особенно если я собираюсь логировать чат пользователей на определенный период?

Зачем шифровать весь трафик mmo соединения? вместо использования хешсумм. Насколько я понимаю - просто потому что это банально производительней и меньше раздувает траффик, или я ошибаюсь?

PS: просто скажите как делают в реальных играх? в реальных конторах?

#9
10:08, 31 янв. 2018

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

#10
10:11, 31 янв. 2018

gamedeveloper01
> вместо использования хешсумм. Насколько я понимаю - просто потому что это
> банально производительней
Не уверен. openssl в тесте на скорость у меня показывает 800 мб/с для md5,  1.1 гб/с для sha1 и 6.2 гб/с для aes-128-gcm.

#11
10:22, 31 янв. 2018

entryway
> Не уверен. openssl в тесте на скорость у меня показывает 800 мб/с для md5,  1.1
> гб/с для sha1 и 6.2 гб/с для aes-128-gcm.
AES быстрее? так я и говорю об этом вроде, ты не так понял.

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

Почему без сертификатов (почему не взять TLS)? насколько я знаю никто так не делает для таких целей.

Мне вот в частности интересно, как сделано соединение к лобби у Fortnite или PUBG или у чего то подобного, но более простого.

#12
10:40, 31 янв. 2018

gamedeveloper01
> просто скажите как делают в реальных играх? в реальных конторах?
Не защищают трафик вообще в играх. Только при начале сеанса хоть что-то делают, чтобы чужой аккаунт не слямзили, и все.

#13
10:51, 31 янв. 2018

Zab
> Не защищают трафик вообще в играх. Только при начале сеанса хоть что-то делают,
> чтобы чужой аккаунт не слямзили, и все.
Ну я сомневаюсь что например в EvE Online трафик никак не защищают, хотябы чтобы была небольшая гарантия что у тебя не сломают все предметы и не переведут все деньги на другой аккаунт. Тоже самое может быть и в других играх, например в доте 2 вещи в инвентаре можно уничтожать, вот представь у тебя удалят хук пуджа и все арканы - техподдержке тоже проблем таких не нужно.

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

#14
11:32, 31 янв. 2018

Тред не читал, но для
>Не дать man-in-middle изменить их
есть криптографические подписи. Простой хэш или сумму применять категорически нельзя, так как оно легко подделывается.

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

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумСеть