WS
Критерий такой, что процессы будут в 5 раз медленнее. Обосновать необходимость этого сложно
Size: a a a
2020 July 31
WS
ну это типа ECNR, только для второй компоненты подписи используется симметрический шифр, туда можно тело сообщения запихать
Хм, интересно. Посмотрю, спасибо
WS
ну кароче суть того что я хотел сказать примерно в том, что экономить надо когда реально надо. а грустновато - так себе критерий )
Фактически, я пытаюсь сделать систему с несколькими вариантами и работы и свойствами. Например, можно допустить неаутентифицированные маленькие сообщения, получится один вариант. Можно аутентифицировать, получится другой. Уже в моделях станет ясно реальное влияние. Референсный вариант вообще без криптографии)
a
криптография требует байтов ) так или иначе +10 байт скорее всего будет
WS
Это понятно) хочется как раз посмотреть, какой оверхед будет в разных случаях (режимах)
JG
криптография требует байтов ) так или иначе +10 байт скорее всего будет
Квантовая - нет
AW
Квантовая - нет
Ой мама
W
Переслано от Wow
Йо, написал ещё один DNS тоннель на основе тулы dns2tcp, но который пробрасывает порты как plink с опциями -L/-R. Работает стабильно и без обрывов в отличии от например dnscat, iodine и других. Клиент не требует привилегий администратора и бинари есть как для windows так и для linux. Сервер только на linux. Скорость от клиента 12кб/c, от сервера ещё выше. При разработке много внимания уделил стабильности. https://github.com/kirillwow/dns2tcp
K
Переслано от Wow
Йо, написал ещё один DNS тоннель на основе тулы dns2tcp, но который пробрасывает порты как plink с опциями -L/-R. Работает стабильно и без обрывов в отличии от например dnscat, iodine и других. Клиент не требует привилегий администратора и бинари есть как для windows так и для linux. Сервер только на linux. Скорость от клиента 12кб/c, от сервера ещё выше. При разработке много внимания уделил стабильности. https://github.com/kirillwow/dns2tcp
👍
2020 August 01
VR
Каналы бывают очень медленными. Потому крайне желательно минимизировать размеры. Если пейлоад 10 байт, то оверхед в 40 выглядит грустновато
Я чутка слоу, но можно например подписывать несколько фреймов сразу, чтобы избежать большого оверхеда. В ситуации когда бродкастом пуляется по одному пакету (arp например), подписываем только этот фрейм, но оверхед не создаёт большой нагрузки на канал тк пакеты одиночные
В ситуации когда льётся поток (напр iptv), набиваем в буфер 8 фреймов, и подписываем их в сумме, подпись пихая только в первый - на потоке получается оверхед в восемь раз меньше
В ситуации когда льётся поток (напр iptv), набиваем в буфер 8 фреймов, и подписываем их в сумме, подпись пихая только в первый - на потоке получается оверхед в восемь раз меньше
WS
Я чутка слоу, но можно например подписывать несколько фреймов сразу, чтобы избежать большого оверхеда. В ситуации когда бродкастом пуляется по одному пакету (arp например), подписываем только этот фрейм, но оверхед не создаёт большой нагрузки на канал тк пакеты одиночные
В ситуации когда льётся поток (напр iptv), набиваем в буфер 8 фреймов, и подписываем их в сумме, подпись пихая только в первый - на потоке получается оверхед в восемь раз меньше
В ситуации когда льётся поток (напр iptv), набиваем в буфер 8 фреймов, и подписываем их в сумме, подпись пихая только в первый - на потоке получается оверхед в восемь раз меньше
Не слоу, тема по-прежнему актуальна :) Да, агрегация конечно вещь хорошая, буду делать :) Но конкретно здесь о другом. Раскрою чуть больше инфы о системе. Маленькие фреймы — в моем случае это например аналог RTS/CTS из Wifi. Они для организации доступа к среде используются, поэтому минимизация их длительности особенно нужна - чтобы коллизии уменьшить.
F
Привет. Кто-нибудь интересовался, со стороны наблюдателя с картой в режиме мониторинга mesh точку доступа от обычной как-то можно отличить?
Есть ли в Питере общественные mesh сети?
Есть ли в Питере общественные mesh сети?