Форум на Исходниках.RU

TCP_NODELAY

Alexandoros — Mon, 21 Sep 2009 15:30:26 +0000

Alexandoros:

Цитата

Но, к сожалению, та функция по частям расшифровывать не умеет,

В этом случае поможет написание своей ф-ции для рассшифровки. Если алгоритм стандартне и документирован, то проблем не должно возникнуть.

TCP_NODELAY

Хрен — Fri, 18 Sep 2009 17:02:45 +0000

Хрен: Да, ступил чуть-чуть. Но, к сожалению, та функция по частям расшифровывать не умеет, т.к. после расшифровки проверяет текст на целостность при помощи сравнения имитовставок. Так что ничего не получилось бы.
Но это ужо не важно - решили всё-таки ставить заголовки с длиной пакета =)
Всем спасибо.

TCP_NODELAY

Alexandoros — Thu, 17 Sep 2009 09:35:38 +0000

Alexandoros: Может я туплю в чем то, но как раз здесь все получится по 8 байт расшифровывать. Объясни проблему.

Алгоритм - получаем первый блок(8байт), расшифровуем, результат используем для разшифровки второго блока, результат второго для третьего и т.д. В чем проблема, я не пойму?

TCP_NODELAY

Хрен — Thu, 17 Sep 2009 09:21:37 +0000

Хрен: ГОСТ28147-89 - блочный симметричный алгоритм шифрования. Как и большинство БСШ, имеет 3 режима шифрования:
1. простой замены - текст берётся поблочно (блок - 8 байт) и каждый блок шифруется непосредственно на ключе;

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

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

У нас используется 3-й режим. Поэтому читать по 8 байт и расшифровывать отдельно каждый блок не получится =(

TCP_NODELAY

Alexandoros — Thu, 17 Sep 2009 08:56:02 +0000

Alexandoros: ГОСТ это стандарт или название протокола?
Описалово/дока имелось в виду.

TCP_NODELAY

Хрен — Thu, 17 Sep 2009 08:29:43 +0000

Хрен: ГОСТ писали не мы, и исходников у нас нет. Так что тут беда с этим =)

TCP_NODELAY

Alexandoros — Thu, 17 Sep 2009 07:56:18 +0000

Alexandoros: Гост в студию плиз.

TCP_NODELAY

Хрен — Thu, 17 Sep 2009 07:03:08 +0000

Хрен: Да, это хорошо. Но проблема в том, что в функции шифрования используется ГОСТ с обратной связью (только что узнал). Так что отдельно блоки расшифровать не получится =(

TCP_NODELAY

Хрен — Wed, 16 Sep 2009 19:45:05 +0000

Хрен: Нет. Есть совершенно отдельные пакеты данных.
<пакет>
<пакет>
.......
<пакет>

Каждый из них заканчивается меткой перевода каретки \r\n.
Каждый пакет ОТДЕЛЬНО шифруется на ГОСТе.
<зашифрованный пакет>
<зашифрованный пакет>
.......
<зашифрованный пакет>

Эти пакеты генерируются, шифруются и передаются ОТДЕЛЬНО, в разные промежутки времени. А на сервере иногда принимаются в следующем виде:
1-й RECV:
<зашифрованный пакет><зашифрованный пакет><зашифрован
2-й RECV:
ный пакет><зашифрованный пакет>

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

Вот.

TCP_NODELAY

Хрен — Wed, 16 Sep 2009 19:29:56 +0000

Хрен: Походу, мы друг-друга не особо понимаем =)
Приведи пример, как ты себе эту систему видишь. Может я до чего-то элементарного допереть не могу - бывает :)

TCP_NODELAY

Хрен — Wed, 16 Sep 2009 19:07:57 +0000

Хрен:

Цитата

Что тебе мешает сначала добавить метки, затем поток зашифровать?

Так пакеты шифруются каждый по отдельности на клиенте. А на сервере приходит это нагромождение пакетов, причём вполне возможно, что один из них неполный. Как разделить уже зашифрованные пакеты, и какая разница, были метки в открытых пакетах или нет (в открытых пакетах они, кстати, есть) =)

Добавлено 16.09.09, 19:11

Цитата albom @ 16.09.09, 18:51

Экранирование escape последовательностой полвека назад придумали .

Наверно чего-то недопонял. Пример, допустим, 2-х шифртекстов, разделённых этой самой "экранированной" последовательностью, могёшь показать?

TCP_NODELAY

Хрен — Wed, 16 Sep 2009 18:48:10 +0000

Хрен: Вызвано это тем, что идут шифрованные данные.
Во-первых, понижается безопасность, т.к. можем этим выдать смысл зашифрованных данных.
Во-вторых, нет 100% гарантии, что в криптотексте не получится набора символов, аналогичных метке.

Всё это не потому что мне так хочется =)

TCP_NODELAY

Хрен — Wed, 16 Sep 2009 16:34:41 +0000

Хрен:

Цитата

И разделителей или других псевдозаголовков тоже ставить нельзя. Короче, модификацию протокола не предлагать =)

К сожалению, это не вариант :(

Добавлено 16.09.09, 16:53
Тогда такой вопрос... При работе с RAW сокетами предусмотрен какой-нибудь автоматический фильтр по портам хотя бы? Или мы будем обязательно принимать все пакеты, которые поступили на комп, и разбирать всё придётся вручную?

TCP_NODELAY

Alexandoros — Wed, 16 Sep 2009 15:01:21 +0000

Alexandoros: Размер пакета включать в пакет. Расшифровал первый, откусил от общего буфера и т.д.

TCP_NODELAY

Хрен — Wed, 16 Sep 2009 14:43:09 +0000

Хрен: Т.е. единственный вариант, получается, SOCK_RAW и парсить?

TCP_NODELAY

Хрен — Wed, 16 Sep 2009 13:05:20 +0000

Хрен: Доброго времени всем!
Ситуация у меня следующая:
Есть клиент, который передаёт небольшие (до 128 байт) пакеты данных разной длины по протоколу TCP. И есть сервер, которые эти данные принимает.
Дело в том, что пакеты на клиенте шифруются, каждый отдельно. Следовательно, для их успешной расшифровки необходимо их принимать так же отдельно. Но коварный (в нашем случае) алгоритм Нейгла не даёт принимать все пакеты отдельно, и приходят они иногда склеенными, разорванными и не подлежащими разбиению на правильные куски.
Я подумываю о TCP_NODELAY, но на довольно многих форумах встречал высказывания, которые гласили, что TCP_NODELAY, дескать, ересь, и программистам, которые его используют, вечная анафема =)

Кто что посоветовать могёт по этому поводу? Протокол на UDP менять нельзя. И разделителей или других псевдозаголовков тоже ставить нельзя. Короче, модификацию протокола не предлагать =)

Заранее спасибо