Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Как защитить пакеты от изменения? какие чексуммы нужны? (2 стр)

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

Страницы: 1 2 3 Следующая »
gamedeveloper01Постоялецwww31 янв. 201811:49#15
neumond
> Соль нужна только для подмешивания в вычисление хэшей
То есть я не могу подмешать соль (секретный токен) в вычисление CRC32? Это будет как бы совсем не безопасно? или какая то безопасность всё таки будет? Хотя бы для чата.

Я выяснил как это по научному называется, такие подписи, вроде:
HMAC-MD5, HMAC-SHA1 ...
Короче приставка HMAC.

Правка: 31 янв. 2018 12:03

neumondПостоялецwww31 янв. 201812:08#16
Не будет безопасности, так как можно к примеру дописать сообщение и прибавить в сумму добавленный текст. Точно такие же операции можно сделать с хэшами, причём не важно насколько там всё изначально засолили.
Ещё раз, соль это только для того чтобы нельзя было использовать радужные таблицы. Например в БД хранятся md5 от паролей пользователей, хакер украл базу и используя предвычисленные md5 может не убивать время на подбор этих md5, практически без затрат вынуть пароли. Соль же дописывается к паролю при взятии md5, от этого такой заранее заготовленный словарь становится неактуален.
gamedeveloper01Постоялецwww31 янв. 201812:12#17
neumond
> Не будет безопасности, так как можно к примеру дописать сообщение и прибавить в
> сумму добавленный текст.
Лол ясно.

neumond
> Точно такие же операции можно сделать с хэшами, причём не важно насколько там
> всё изначально засолили.
Это как? серьезно чтоли? то есть HMAC тоже бесполезны и не дадут гарантии что к сообщению ничего не добавили?

Правка: 31 янв. 2018 12:13

neumondПостоялецwww31 янв. 201812:16#18
Нет, HMAC не бесполезны, так как там не просто хэш от контента берётся. А сами хэши таки да, обладают свойством потоковости: имея хэш некоторого контента A можно вычислить хэш A+B, при этом не имея на руках оригинального контента A (который в вашем случае будет соль+текст сообщения), в общем примерно как с суммой.
gamedeveloper01Постоялецwww31 янв. 201812:29#19
neumond
Ок.

Мне тут посоветовали poly1305, который даёт 16 байт результат, вроде звучит неплохо. Потому что HMAC-SHA256 даст уже 32 байта - как то по моему многовато

Нашел еще вот что, пока что изучаю:
https://gist.github.com/atoponce/07d8d4c833873be2f68c34f9afc5a78a
PS: вот бы типа такого документа, только для игр.

Правка: 31 янв. 2018 12:34

gamedeveloper01Постоялецwww31 янв. 201814:37#20
Например вот что нам предлагает Unity:
https://docs.unity3d.com/ScriptReference/Network.InitializeSecurity.html

Видно что они используют RSA + AES.

А также пишут: Adds CRCs so that data tampering can be detected, только не совсем понятно зачем это, если они уже используют AES.

kiparПостоялецwww31 янв. 201821:14#21
gamedeveloper01
Просто шифровать - недостаточно.
Вот идет обмен зашифрованым трафиком, человек в середине может начать менять разные биты и смотреть как на это отреагируют участники. В итоге или повлиять на данные или вычислить ключ, ну там от конкретного сценария зависит. Например если AES используется в режиме ECB, то сообщение легко дешифровывается просто по внешнему виду. Или, например, можно записывать тот трафик который был послан и отправлять его заново чтоб сэмулировать повтор события (заставить например игрока заплатить дважды).

В общем любое сообщение должно подписываться (MAC), в нем должен быть nonce, ну и AES должен использоваться в правильном режиме. Там вообще очень много ньюансов (шифровать до вычисления контрольной суммы или после, где указывать длину ведь длины может быть достаточно чтобы отличить одни пакеты от других, ну и т.д.), любая мелкая ошибка приводит к решету вместо безопасности. Поэтому вопрос должен стоять не "как мне подписывать пакеты", а "какую готовую библиотеку (и какие алгоритмы\функции из нее) использовать". Берешь libsodium и не заморачиваешься. Или monocypher. Или NaCL. Для игр тем более, ведь в играх ты обе стороны пишешь, тебя не заставляют какое-нибудь говно мамонта типа DES использовать только потому что его в прошлом веке приняли как стандарт.

gamedeveloper01Постоялецwww31 янв. 201821:40#22
kipar
Так ну ок. Теперь вроде ясно зачем еще и CRC может понадобиться для каждого пакета, даже внутри AES. Чтобы не особо получилось поменять даже зашифрованный пакет на что нибудь непонятное и потенциально опасное. Также у каждого пакета есть параметр длины, так что добавить лишних байт пакету не получится и CRC32 должен сработать, зачем целый MAC внутри AES?

Вроде в .net framework по умолчанию используется AES-gcm, насколько я понял, так что всё должно быть нормально.

gamedeveloper01
> где указывать длину ведь длины может быть достаточно чтобы отличить одни пакеты
> от других
Длину указывать внутри AES, снаружи вообще ничего не указывать.

kipar
> шифровать до вычисления контрольной суммы или после
Шифровать после же? вместе с контрольной суммой.

kipar
> Берешь libsodium и не заморачиваешься
libsodium.net сделан только для osx, linux и windows, самому делать порт не моё. Ну и кроме того, я там не нашел симметричного алгоритма, там много всякого, а AES или подобных не вижу, чем там шифровать трафик то?

Клиент в частности будет на unity3d (может на андроид тоже), а для ue4 клиента буду использовать ихний openssl, он должен хорошо стыковаться с .net core стороной на сервере. А подключать к ue4 C++ libsodium тоже как то геморно. В общем я планирую использовать только чистый .NET, а в случае с UE4 openssl на клиенте.

Правка: 31 янв. 2018 21:54

kiparПостоялецwww31 янв. 201821:56#23
gamedeveloper01
> Также у каждого пакета есть параметр длины
4 байта? Но ведь я их тоже могу менять. Ну т.е. беру, меняю что-то в пакете, потом отправляю по кусочкам большой массив данных и смотрю на каком кусочке сервер прекратит ожидать данные. Вуаля, вот я и выяснил на что повлияли мои изменения, это сильно облегчит подбор ключа. Или длина вообще не зашифрована?


crc32 слишком уязвим. Он же от случайных помех сделан, а не от зловредных.

> а AES или подобных не вижу, чем там шифровать трафик то?
ChaCha20. Он намного надежнее и быстрее AES.


> Шифровать после же? вместе с контрольной суммой.
В этом случае мы открываем возможность злоумышленнику по всякому менять пакет пытаясь на что-то повлиять. На этом основано много разных атак. Poly1305 сделан чтобы подписывать ПОСЛЕ шифрования. Т.е. берем пакет, проверяем MAC, если он не сошелся сразу выбрасываем, если сошелся то он гарантированно нормальный, можно расшифровывать.

Правка: 31 янв. 2018 22:01

gamedeveloper01Постоялецwww31 янв. 201822:00#24
kipar
> 4 байта? Но ведь я их тоже могу менять. Ну т.е. беру, меняю что-то в пакете,
> потом отправляю по кусочкам большой массив данных и смотрю на каком кусочке
> сервер прекратит ожидать данные. Вуаля, вот я и выяснил на что повлияли мои
> изменения, это сильно облегчит подбор ключа. Или длина вообще не зашифрована?
Длина зашифрована. Но каков шанс, что получится поменять длину, да еще и чтобы CRC32 совпала, по моему это бред. Разве нет?

kipar
> crc32 слишком уязвим. Он же от случайных помех сделан, а не от зловредных.
Ну фиг знает, это всё таки игра, а не пентагон. Взламывать CRC внутри AES, чтобы она еще с длиной совпала, которая тоже внутри AES... я хоть и не спец, но думаю это не так просто.

gamedeveloper01
> ChaCha20. Он намного надежнее и быстрее AES.
Ясно, но думаю всё равно libsolium для меня не вариант по причинам которые я написал выше.

Правка: 31 янв. 2018 22:02

kiparПостоялецwww31 янв. 201822:03#25
gamedeveloper01
зачем если можно сразу сделать невзламываемо (на современном уровне развития криптографии).
gamedeveloper01Постоялецwww31 янв. 201822:07#26
kipar
> зачем если можно сразу сделать невзламываемо (на современном уровне развития
> криптографии).
Думаю это бесполезно. Хочу оставаться в рамках .NET framework во всяком случае.

PS: так стоп, сейчас читаю чего то, и вроде же AES-GCM - где GCM означает MAC, то есть свой CRC даже использовать не нужно? всё включено так сказать, и по уму.

PS2: я тут параллельно узнал, что вроде в .NET нет AES-GCM, там только обычный AES без MAC (https://github.com/dotnet/corefx/issues/7023), видимо поэтому в Unity упоминается CRC в связке с AES. Да это типо не супер безопасно и всё такое, но хоть что то ведь. Но могу и ошибаться, может AesCng и работает в режиме AES-GCM...  пока не пойму.

Правка: 31 янв. 2018 23:25

BishopПостоялецwww1 фев. 20180:07#27
Боже. Что вы тут развели? Вот честное слово...

Автору: заодно отвечу в этой теме и на твой второй топик.

Значит так. CRC32 пригоден ТОЛЬКО для решения проблем с аппаратными ошибками. Там память битая, ошибка при передаче по сети и т.д. Он вообще НИКАКОГО отношения к криптографии не имеет.

Теперь о установке соединения, всяких RSA/DHE и прочей элиптике. Во-первых если у тебя проблемы с производительностью => разбираться в элиптике (причём именно разбираться). Если нужно просто и надёжно (но ценой большей вычислительной сложности) - RSA+DHE. Эти алгоритмы хороши по 2-м причинам: один старые (т.е. шишек уже набили и понятна в том числе потерниальная сложность взлома для множества мат. методов + они математически простые, их легко понять самому => меньше шанс что тебе подсунут непойми-что). Сложность сейчас нужно брать от 4096 бит (для игр сойдёт, для более серьёзных вещей идёт уже от 8192).

Мой личный выбор алгоритмов таков: RSA+DHE+AES-256-CTR+SHA512 (в качестве HMAC можно использовать или AES-HMAC, или SHA256 или SHA512... у каждого свои плюсы в отношении реализации на x86_64). Лично я GCM не приветствую.

Потом о сертификатах... это просто форма для RSA/ECDSA и не более того. Просто стандарт. С точки зрения безопасности всё тоже самое можно сделать и самому.

gamedeveloper01Постоялецwww1 фев. 20180:33#28
Bishop
> RSA+DHE+AES-256-CTR+SHA512
Теперь только надо поподробней понять данную связку. Уже точно не сегодня.

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

Правка: 1 фев. 2018 0:43

ZabПостоялецwww1 фев. 20181:03#29
Если сеанс начинается через RSA, нафига вам хеши? Хеши, они для случаев когда вообще ничего не шифруется. С RSA вам и пароль то не нужен, что вы хешем обрабатывать собрались?

Правка: 1 фев. 2018 1:05

Страницы: 1 2 3 Следующая »

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

2001—2018 © GameDev.ru — Разработка игр