Отличные предложения. На самом деле, если Вам интересно, то в статье авторы разбирают многие из техник, которые Вы предложили (и придуманы они уже давно). Всего авторы приводят 3 типа стеганографии при помощи TCP: (i) модификация пакетов и хедеров, (ii) модификация свойств соединения (изменение порядка следования пакетов, варьирование времени между пакетами и т.д.) и (iii) гибридные. Свой метод авторы относят к последней категории.
Все верно. Но при этом в статье также рассматриваются случаи когда отправитель оригинальных пакетов, получатель оригинальных пакетов или же оба не знают о факте передачи скрытых данных. Т.е. в этих случаях стороны, обменивающиеся стеганограммой частично или полностью «паразитируют» на существующих соединениях. В этих сценариях факт установки соединения и факт передачи данных роли не играют, поскольку конечные узлы — не участники «тайной» передачи. Само собой в этих сценариях есть недостаток — паразитирующие узлы должны иметь возможность перехватывать все пакеты в соединении.
Нет, не отменили. Но все дело в том, что при помощи сокетов нельзя полностью контролировать работу TCP. Например нельзя «заказать» ретрансмиссию когда захочется. Если исходный пакет был получен корректно, то ядро не будет посылать запрос на ретрансмиссию — зачем? И, кстати, если все-таки «тайная» ретрансмиссия будет иметь место, то обычное ядро будет отбрасывать такие пакеты считая их дубликатами, ведь sequence number у них будет совпадать с уже полученными пакетами. Кратко говоря, для этого метода нужно иметь возможность контролировать работу TCP/IP стэка на уровне ядра, уровень raw socket'ов слишком высок для этого.
Все верно, а зачем им отличаться? Они выглядят как обычная ретрансмиссия для этого соединения — те же порт, IP, правильные sequence number и так далее. Просто вместо «обычных» данных вставляем «тайные».
Да, сами авторы даже и не стали реализовывать — ограничились симуляцией. А вообще тема интересная, но что-то хабронарод не впечатлила. Видимо сложноват материал для среднего хабраюзера.
Теоретически можно поймать и на пересылке в ретрансмиссии. Но практически это сделать очень сложно. Через даже среднего провайдера в секунду проходит столько пакетов, что всех их проинспектировать очень затруднительно в плане вычислительных ресурсов. Если бы целиком все TCP соединение представляло собой тайную переписку, то достаточно было бы поймать и проанализировать всего лишь несколько пакетов. Но как было правильно подмечено, ретрасмиссия происходит достаточно редко поэтому поймать становится еще во много раз сложнее чем случае с целым TCP соединением.
Согласен, обработка обработке рознь. Само собой на Большом Адронном Коллайдере они не собираются просто сортировать полученные данные. Я привел примеры просто чтобы народ почуствовал, что такое петабайт.
К сожалению в гугловском блоге подробностей нет. Но написано, что через некоторое время будет публикация с описанием эксперимента. Я думаю там и расскажут про алгоритм.
Ну, если читатель через неделю сможет вспомнить из всей статьи только заголовок, то это конечно плохо. Я не думаю, что я вспоминаю статьи по заголовкам. Из хорошей статьи ИМХО выносится какое-либо «знание», которое и вспоминается через неделю.
Я в своем комментарии, кстати, ничего не говорил о «запоминаемости» заголовков. Я рассуждал о заголовке как о средстве привлечения читателя, т.е. о «броскости» заголовков.
Кстати, было бы интересно услышать ваше мнение по двум вопросам, которые я задал в предыдущем комментарии. Можно применительно к Хабру или не только.
Я в своем комментарии, кстати, ничего не говорил о «запоминаемости» заголовков. Я рассуждал о заголовке как о средстве привлечения читателя, т.е. о «броскости» заголовков.
Кстати, было бы интересно услышать ваше мнение по двум вопросам, которые я задал в предыдущем комментарии. Можно применительно к Хабру или не только.