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

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

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

neumond
> Соль нужна только для подмешивания в вычисление хэшей
То есть я не могу подмешать соль (секретный токен) в вычисление CRC32? Это будет как бы совсем не безопасно? или какая то безопасность всё таки будет? Хотя бы для чата.

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


#16
12:08, 31 янв. 2018

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

#17
12:12, 31 янв. 2018

neumond
> Не будет безопасности, так как можно к примеру дописать сообщение и прибавить в
> сумму добавленный текст.
Лол ясно.

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

#18
12:16, 31 янв. 2018

Нет, HMAC не бесполезны, так как там не просто хэш от контента берётся. А сами хэши таки да, обладают свойством потоковости: имея хэш некоторого контента A можно вычислить хэш A+B, при этом не имея на руках оригинального контента A (который в вашем случае будет соль+текст сообщения), в общем примерно как с суммой.

#19
12:29, 31 янв. 2018

neumond
Ок.

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

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

#20
14:37, 31 янв. 2018

Например вот что нам предлагает Unity:
https://docs.unity3d.com/ScriptReference/Network.InitializeSecurity.html

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

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

#21
21:14, 31 янв. 2018

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

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

#22
21:40, 31 янв. 2018

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 на клиенте.

#23
21:56, 31 янв. 2018

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


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

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


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

#24
22:00, 31 янв. 2018

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

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

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

#25
22:03, 31 янв. 2018

gamedeveloper01
зачем если можно сразу сделать невзламываемо (на современном уровне развития криптографии).

#26
22:07, 31 янв. 2018

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...  пока не пойму.

#27
0:07, 1 фев. 2018

Боже. Что вы тут развели? Вот честное слово...

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

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

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

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

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

#28
0:33, 1 фев. 2018

Bishop
> RSA+DHE+AES-256-CTR+SHA512
Теперь только надо поподробней понять данную связку. Уже точно не сегодня.

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

#29
1:03, 1 фев. 2018

Если сеанс начинается через RSA, нафига вам хеши? Хеши, они для случаев когда вообще ничего не шифруется. С RSA вам и пароль то не нужен, что вы хешем обрабатывать собрались?

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