Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[52.14.84.29] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Доброго времени всем!
Ситуация у меня следующая: Есть клиент, который передаёт небольшие (до 128 байт) пакеты данных разной длины по протоколу TCP. И есть сервер, которые эти данные принимает. Дело в том, что пакеты на клиенте шифруются, каждый отдельно. Следовательно, для их успешной расшифровки необходимо их принимать так же отдельно. Но коварный (в нашем случае) алгоритм Нейгла не даёт принимать все пакеты отдельно, и приходят они иногда склеенными, разорванными и не подлежащими разбиению на правильные куски. Я подумываю о TCP_NODELAY, но на довольно многих форумах встречал высказывания, которые гласили, что TCP_NODELAY, дескать, ересь, и программистам, которые его используют, вечная анафема =) Кто что посоветовать могёт по этому поводу? Протокол на UDP менять нельзя. И разделителей или других псевдозаголовков тоже ставить нельзя. Короче, модификацию протокола не предлагать =) Заранее спасибо |
Сообщ.
#2
,
|
|
|
Т.е. единственный вариант, получается, SOCK_RAW и парсить?
|
Сообщ.
#3
,
|
|
|
Размер пакета включать в пакет. Расшифровал первый, откусил от общего буфера и т.д.
|
Сообщ.
#4
,
|
|
|
Цитата И разделителей или других псевдозаголовков тоже ставить нельзя. Короче, модификацию протокола не предлагать =) К сожалению, это не вариант :( Добавлено Тогда такой вопрос... При работе с RAW сокетами предусмотрен какой-нибудь автоматический фильтр по портам хотя бы? Или мы будем обязательно принимать все пакеты, которые поступили на комп, и разбирать всё придётся вручную? |
Сообщ.
#5
,
|
|
|
Вызвано это тем, что идут шифрованные данные.
Во-первых, понижается безопасность, т.к. можем этим выдать смысл зашифрованных данных. Во-вторых, нет 100% гарантии, что в криптотексте не получится набора символов, аналогичных метке. Всё это не потому что мне так хочется =) |
Сообщ.
#6
,
|
|
|
Цитата Что тебе мешает сначала добавить метки, затем поток зашифровать? Так пакеты шифруются каждый по отдельности на клиенте. А на сервере приходит это нагромождение пакетов, причём вполне возможно, что один из них неполный. Как разделить уже зашифрованные пакеты, и какая разница, были метки в открытых пакетах или нет (в открытых пакетах они, кстати, есть) =) Добавлено Наверно чего-то недопонял. Пример, допустим, 2-х шифртекстов, разделённых этой самой "экранированной" последовательностью, могёшь показать? |
Сообщ.
#7
,
|
|
|
Походу, мы друг-друга не особо понимаем =)
Приведи пример, как ты себе эту систему видишь. Может я до чего-то элементарного допереть не могу - бывает |
Сообщ.
#8
,
|
|
|
Нет. Есть совершенно отдельные пакеты данных.
<пакет> <пакет> ....... <пакет> Каждый из них заканчивается меткой перевода каретки \r\n. Каждый пакет ОТДЕЛЬНО шифруется на ГОСТе. <зашифрованный пакет> <зашифрованный пакет> ....... <зашифрованный пакет> Эти пакеты генерируются, шифруются и передаются ОТДЕЛЬНО, в разные промежутки времени. А на сервере иногда принимаются в следующем виде: 1-й RECV: <зашифрованный пакет><зашифрованный пакет><зашифрован 2-й RECV: ный пакет><зашифрованный пакет> Надо их разделить. Проблема в том, что если даже забить на секюрность и использовать разделители, то не факт, что текст этого разделителя не встретится где-нибудь в теле шифропакета. Понятно, что чем длиннее разделитель, тем меньше шанс коллизии, но всё-таки хотелось бы эту возможность исключить. Вот. |
Сообщ.
#9
,
|
|
|
Да, это хорошо. Но проблема в том, что в функции шифрования используется ГОСТ с обратной связью (только что узнал). Так что отдельно блоки расшифровать не получится =(
|
Сообщ.
#10
,
|
|
|
Гост в студию плиз.
|
Сообщ.
#11
,
|
|
|
ГОСТ писали не мы, и исходников у нас нет. Так что тут беда с этим =)
|
Сообщ.
#12
,
|
|
|
ГОСТ это стандарт или название протокола?
Описалово/дока имелось в виду. |
Сообщ.
#13
,
|
|
|
ГОСТ28147-89 - блочный симметричный алгоритм шифрования. Как и большинство БСШ, имеет 3 режима шифрования:
1. простой замены - текст берётся поблочно (блок - 8 байт) и каждый блок шифруется непосредственно на ключе; 2. гаммирования - при помощи алгоритма шифруется 8 байт начального текста, который называется синхропосылкой и отправляется вместе с шифртекстом. Результат шифрования синхропосылки складывается с блоком открытого текста по модулю 2, и затем снова шифруется, и складывается со следующим блоком открытого текста и т.д. 3. гаммирования с обратной связью - то же, что гаммирования, однако в шифровании каждого следующего блока участвует результат зашифрования предыдущего блока. Т.е. получается лавинный эффект. У нас используется 3-й режим. Поэтому читать по 8 байт и расшифровывать отдельно каждый блок не получится =( |
Сообщ.
#14
,
|
|
|
Может я туплю в чем то, но как раз здесь все получится по 8 байт расшифровывать. Объясни проблему.
Алгоритм - получаем первый блок(8байт), расшифровуем, результат используем для разшифровки второго блока, результат второго для третьего и т.д. В чем проблема, я не пойму? |
Сообщ.
#15
,
|
|
|
Да, ступил чуть-чуть. Но, к сожалению, та функция по частям расшифровывать не умеет, т.к. после расшифровки проверяет текст на целостность при помощи сравнения имитовставок. Так что ничего не получилось бы.
Но это ужо не важно - решили всё-таки ставить заголовки с длиной пакета =) Всем спасибо. |