Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет?
Т.е. если пакет неизвестно от кого, чтобы сетевое оборудование его не передавало?
У России есть собственные процессоры и компьютеры, шифры тоже (ГОСТ какой-то там),
ну вот, сделать, чтобы принципиально не работали всякие оверлейные сети типа retroshare,
где абоненты пытаются что-то пересылать через провайдеров-юридических лиц.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет? ЭФ>Т.е. если пакет неизвестно от кого, чтобы сетевое оборудование его не передавало?
Можно но зачем? Вы хотите что бы можно было человека посадить по подписи сетевого пакета? (Ключ конечно же в TPM2.0 хранить)
ЭФ>У России есть собственные процессоры и компьютеры, шифры тоже (ГОСТ какой-то там), ЭФ>ну вот, сделать, чтобы принципиально не работали всякие оверлейные сети типа retroshare, ЭФ>где абоненты пытаются что-то пересылать через провайдеров-юридических лиц.
В России пока семимильными шагами развивается только штрафадобывающая отрасль. Вы хотите принять участие в этом процессе?
_> Вы хотите что бы можно было человека посадить по подписи сетевого пакета?
Я глубоко возмущён тем, что программы тип Retroshare, ejabberd, synapse (matrix server)
и другие подобного рода (например Telegram) не соответствуют российскому законодательству.
Согласно нему, каждый пользователь системы мгновенных сообщений должен быть идентифицирован
по номеру сотового телефона.
_> развивается только штрафадобывающая отрасль
Был бы человек. И подписи каждого пакета помогут его идентифицировать.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет? ЭФ>Т.е. если пакет неизвестно от кого, чтобы сетевое оборудование его не передавало?
В TCP/IP это не возможно, у тебя MTU обычно не больше 1500 байт, куда там подпись запихнуть? Да и рассчитывать подпись для каждого пакета в реальном времени очень накладно.
Но идея цензуры на подобном уровне есть, и кое где над ней даже работают. Думаю что вполне очевидно, что в ближайшее будущее для предпосылок для перехода TCP/IP -> New IP за пределами Китая нет.
Дядя, а ты точно программист? Ну, это же как бы совсем уж очевидно.
Здравствуйте, Эйнсток Файр, Вы писали:
KP>> 1500 байт, куда там подпись запихнуть?
ЭФ>72 байта говорят под подпись достаточно. ЭФ>Это 5% длины — практически незаметно.
Это почти в 4 раза больше стандартного IP заголовка, что всё же очень дохрена для совершено нелепого функионала. Так же ты почему-то выкинул часть комментария про сложность расчётов в асимметричной криптографии.
ЭФ>Есть. Империалистические и капиталистические противоречия — вот предпосылки. Проявляются в форме ковида.
Если Китаю удастся эксперимент с New IP, возможно страны типа РФ у себя тоже его внедрят. Изменить TCP/IP подобным образом не выйдет просто технически.
KP> ты почему-то выкинул часть комментария про сложность расчётов в асимметричной криптографии
Потому что она ассиметричая как раз потому, что зашифровывать и подписывать менее сложно, чем ломать.
То есть, да, конечно какие-то вычисления потребуются, и надо будет потратить немного больше песка,
чтобы сделать дополнительный чип для сетевой карты. Но это совершенно непринципиальный вопрос, а политический,
если надо — значит надо.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет?
Вполне. WireGuard и инфраструктура CA.
Здравствуйте, kaa.python, Вы писали:
KP>В TCP/IP это не возможно, у тебя MTU обычно не больше 1500 байт, куда там подпись запихнуть? Да и рассчитывать подпись для каждого пакета в реальном времени очень накладно.
Так а подписи много и не надо. В сотню байт Ed25519 вполне укладывается.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ> Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет?
А что в твоем представлении "сетевой пакет"? Но в общем случае — да, можно аутентифицировать (например, IPSec).
ЭФ> ну вот, сделать, чтобы принципиально не работали всякие оверлейные сети типа retroshare,
Нет, нельзя. Ну т.е. теоретически-то конечно все можно, но в текущих реалиях к счастью пока нельзя.
Вот я тоже раньше находился под гипнозом уверенности псевдоспециалистов, таких как kaa.python,
знания которых устарели 20 лет назад.
Алгоритм ECDSA в 1999 г. был принят как стандарт ANSI, в 2000 г. — как стандарт IEEE и NIST
2021-1999=22
AB> т.е. теоретически-то конечно все можно
А тут меня "пробило".
Дальше нужно чётко сформулировать, какие именно реалии мешают.
Я так понимаю, что дело в том, что нет производства оборудования в достаточных объёмах,
но ведь если очень захотеть...
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ> Алгоритм ECDSA в 1999 г. был принят как стандарт ANSI, в 2000 г. — как стандарт IEEE и NIST ЭФ> 2021-1999=22
Эм. А к чему ты привел ECDSA?
ЭФ> Я так понимаю, что дело в том, что нет производства оборудования в достаточных объёмах, ЭФ> но ведь если очень захотеть...
Оборудование ни при чем. Начни с понимания модели OSI. Сначала ты говоришь про подпись пакетов на уровне L3 (если я тебя правильно понял), а потом перепрыгиваешь на уровень L7 (retroshare). Эти уровни никак между собой не связаны — на L7 ты можешь передавать данные через любой доступный низлежащий транспорт (хоть голубинной почтой), а на L3 ты ничего не знаешь о том, какое приложение генерирует данные (можешь лишь предполагать по косвенным признакам, но не более того).
Теоретически ничто не запрещает тебе сделать свою личную сеть, которая на L7 будет пропускать только разрешенный тобой трафик и запрещать любой другой, но в масштабах интернета это будет очень ресурсозатратно и такой сетью никто не захочет пользоваться по своей воле.
Воля есть только у правительства. Прочие люди недоговороспособны
(иначе бы они могли сменить одно авторитарное правительство на другое, но они не могут).
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ> AB> очень ресурсозатратно ЭФ> Абстрактные слова
А какую конкретику ты хочешь услышать? Анализ трафика на L7 требует в сотни-тысячи раз больше вычислительных ресурсов, нежели сейчас тратится на его передачу. Для реализации твоего плана тотального контроля нужно заменить все без исключения медиа (т.е. изъять все имеющиеся, разработать и наладить производство новых, оснастить все новыми).
ЭФ> AB> по своей воле. ЭФ> Воля есть только у правительства. Прочие люди недоговороспособны
Но даже в этом случае, воли правительства недостаточно, чтобы запретить энтропию. А как только у нас появляется энтропия, появляется старый добрый дядька Шеннон и возможность передачи абсолютно любой информации.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет? ЭФ>Т.е. если пакет неизвестно от кого, чтобы сетевое оборудование его не передавало?
ЭФ>У России есть собственные процессоры и компьютеры, шифры тоже (ГОСТ какой-то там), ЭФ>ну вот, сделать, чтобы принципиально не работали всякие оверлейные сети типа retroshare, ЭФ>где абоненты пытаются что-то пересылать через провайдеров-юридических лиц.
Каким образом электронная подпись связана с трафиком оверлейной сети? Что мешает внутри подписанных пакетов передавать зашифрованные пакеты оверлейной сети?
Здравствуйте, Эйнсток Файр, Вы писали:
BFE>> Что мешает внутри подписанных пакетов передавать зашифрованные пакеты оверлейной сети? ЭФ>Процедура выявления всех участников организованной преступной группы.
Каким образом? Что за группа и почему она преступная?
ЭФ>Передал зашифрованные пакеты со своей подписью — знал что делал.
Передавать зашифрованные пакеты запрещено?
ЭФ>Напоминаю, что пакеты будут ходить по белому списку.
Что вы под этим подразумеваете?
Здравствуйте, Cyberax, Вы писали:
C>Так а подписи много и не надо. В сотню байт Ed25519 вполне укладывается.
Всё верно. При этом сотня это не мало в процентном соотношении к величине пакета, плюс ещё эту подпись надо посчитать. Тот же DTLS на который ты ниже ссылаешься (WireGuard на нём, верно?) после установки сессии вполне себе переходит на симметричные потоковые/блочные шифры. Разве нет?
ЭФ>Я глубоко возмущён тем, что программы тип Retroshare, ejabberd, synapse (matrix server) ЭФ>и другие подобного рода (например Telegram) не соответствуют российскому законодательству.
Не пользуйся этими приложениями?
ЭФ>Согласно нему, каждый пользователь системы мгновенных сообщений должен быть идентифицирован ЭФ>по номеру сотового телефона.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет?
Размер непосредственно ec подписи (с 256-битными ключом) 512 битов или 64 байта. Примерно 5% оверхед для типичного размера IP-пакета. Ещё вероятно нужно будет передавать идентификатор публичного ключа, 128 битов должно хватить за глаза, то бишь 80 байтов в сумме. Ещё наверное 32 байта на хеш, подписывать-то хеш будем, а не данные. И на соль 8 байтов. 120 байтов, 10% оверхед. Наверняка можно и оптимальней сделать это всё, это я так, от балды, что в голову пришло в первую очередь. В общем возможно.
Насколько реалистично обрабатывать потоки данных типового провайдера, это я затрудняюсь сказать. Я думаю, что можно сделать специализированное железо для этих алгоритмов. Хотя это будет стоить не один миллион долларов.
ЭФ>ну вот, сделать, чтобы принципиально не работали всякие оверлейные сети типа retroshare, ЭФ>где абоненты пытаются что-то пересылать через провайдеров-юридических лиц.
Для этого достаточно ввести белый список IP, криптография тут ни к чему. И с железом ничего изобретать не нужно, аппаратные фаерволы уже давно у всех стоят.
Я так понял из переписки, что тебе хочется ловить "гадов"?
Для этого не надо подписывать пакеты — все проще, но никто этого делать не станет.
У нас не могут датчики на утечку газа внедрить, чтобы дома не взрывались, а ты пакеты подписывать )
ЭФ>обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет?
Да запросто. Только как это защитит Родину от оверлейных сетей? Что помешает неблагонадёжным гражданам оправлять друг другу пакеты с фотографиями котят, а в эти пакеты вставить скрытую информацию?
И потом, скоро по всей планете будет относительно дешёвый спутниковый тырнет.
Здравствуйте, kaa.python, Вы писали:
C>>Так а подписи много и не надо. В сотню байт Ed25519 вполне укладывается. KP>Всё верно. При этом сотня это не мало в процентном соотношении к величине пакета, плюс ещё эту подпись надо посчитать. Тот же DTLS на который ты ниже ссылаешься (WireGuard на нём, верно?) после установки сессии вполне себе переходит на симметричные потоковые/блочные шифры. Разве нет?
WireGuard не использует DTLS, но там примерно похожий протокол.
Задача же стоит в том, чтобы товарищ майор мог проверить имя, дату рождения и номер паспорта отправителя для каждого пакета? Скорость и надёжность в таком деле не важна.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет?
Для решения этого вопроса давно придумали IPsec.
ЭФ>У России есть собственные процессоры и компьютеры, шифры тоже (ГОСТ какой-то там), ЭФ>ну вот, сделать, чтобы принципиально не работали всякие оверлейные сети типа retroshare, ЭФ>где абоненты пытаются что-то пересылать через провайдеров-юридических лиц.
Может не пакеты тогда ловить, а тотально чипировать мозги, не?
ЭФ>Я глубоко возмущён тем, что программы тип Retroshare, ejabberd, synapse (matrix server) ЭФ>и другие подобного рода (например Telegram) не соответствуют российскому законодательству.
Уж за Телеграм можете не переживать, там все под контролем.
А вы сами-то все законы соблюдаете?
И что будете делать лично вы, когда вас переведут из команды вертухаев в противоположную команду,
"де-юре" благодаря вашей же системе проверки нелегального контента, а
"де-факто" вы даже к компьютеру не подходили, да, что там, компьютер выключен был?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет?
Конечно, это давно придумано и называется IPSEC.
ЭФ>Т.е. если пакет неизвестно от кого, чтобы сетевое оборудование его не передавало?
Это можно сделать (и делают) в масштабах офиса, даже крупного предприятия с филиалами. Но в масштабах РФ не реально.
ЭФ>ну вот, сделать, чтобы принципиально не работали всякие оверлейные сети типа retroshare, ЭФ>где абоненты пытаются что-то пересылать через провайдеров-юридических лиц.
Принципиально — это запретить отключить интернет. Но при этом пожертвовать придется чуть менее, чем всем.
А так это проблема снаряда и брони. Бесконечная гонка. В которой, в отличие от оффлайновых сражений, у атакующего всегда преимущество по ресурсам.
Здравствуйте, Эйнсток Файр, Вы писали:
KP>> ты почему-то выкинул часть комментария про сложность расчётов в асимметричной криптографии ЭФ>Потому что она ассиметричая как раз потому, что зашифровывать и подписывать менее сложно, чем ломать.
Т.е. в случае с симметричной криптографией сложность взлома равняется сложности подписывания? Правильно я вас понял?
Здравствуйте, vsb, Вы писали:
vsb>Размер непосредственно ec подписи (с 256-битными ключом) 512 битов или 64 байта.
21-й век на дворе, боярин. Пора уже вынести из дома RSA и перейти наконец на эллиптические кривые. Там и ключи короче и шифрование при этом надёжнее.
vsb>Ещё наверное 32 байта на хеш, подписывать-то хеш будем, а не данные.
Угу. Но зачем хэш передавать? Данные ведь тут же, рядом. Хэш по ним посчитать можно. И даже нужно — вдруг переданный хэш неправильный?
Update. Впрочем, не, туплю с утра. Надёжный ключ на эллиптических кривых тоже будет в р-не 256 байт. Просто на RSA "надёжный" ключ был бы уже 3072+ бит.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>где абоненты пытаются что-то пересылать через провайдеров-юридических лиц.
В этом смысл провайдеров-юридических лиц, чтобы через них что-то посылать. Можно идентифицировать отправителей-получателей ("я тебя по айпи вычислю, казёл!"), но в общем случае нельзя узнать содержимое. Это такая бесконечная луковица — вылезешь из одного слоя, а там следующий...и конца и края не видно. И все напрасно, и все тлен...
Здравствуйте, Эйнсток Файр, Вы писали:
AK>> надёжнее ЭФ>И ты, конечно, мог бы это доказать?
Я похож на Перельмана? В вопросах криптографии меня максимум на что хватает — понять принципы шифрования, понять характеристики и применимость разных систем шифрования и уметь применить это на практике. Из теоретической же части я вам мог бы рассказать, почему подходы, позволяющие немного снизить количество переборов для RSA, не подходят для эллиптических кривых. Но это надо трындеть на бэк ярде и под пиво. А на клавиатуре на форуме — мне лень.
https://pkic.org/2014/06/10/benefits-of-elliptic-curve-cryptography/
"The foremost benefit of ECC is that it’s simply stronger than RSA for key sizes in use today. The typical ECC key size of 256 bits is equivalent to a 3072-bit RSA key and 10,000 times stronger than a 2048-bit RSA key!"
Здравствуйте, Artem Korneev, Вы писали:
AK>21-й век на дворе, боярин. Пора уже вынести из дома RSA и перейти наконец на эллиптические кривые. Там и ключи короче и шифрование при этом надёжнее.
Я про эллиптические кривые и пишу. С RSA всё гораздо грустней в плане размеров.
AK>Угу. Но зачем хэш передавать? Данные ведь тут же, рядом. Хэш по ним посчитать можно. И даже нужно — вдруг переданный хэш неправильный?
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>Потому что она ассиметричая как раз потому, что зашифровывать и подписывать менее сложно, чем ломать.
Вопрос не в сложности взлома, а в стоимости проверки. Сейчас каждый роутер всего лишь сверяет контрольную сумму пакета.
Ваше предложение означает, что для каждого пакета нужно проверить подпись. Для этого мы:
— берём публичный ключ (допустим, из того же пакета), и шифруем им тело пакета, проверяем результат
— если совпало, то нужно проверить, что публичный ключ принадлежит отправителю пакета. Для этого мы должны где-то взять цепочку сертификатов, и убедиться в её целостности.
— попутно надо проверить каждый сертификат в цепочке по его CRL, скачав его из интернета.
Это, мягко говоря, очень дорого. Не говоря уже о том, что все вот эти "где-то взять" и "скачав из интернета" тоже будут работать через "секьюрный TCP/IP", и для передачи одного пакета через один роутер надо будет передать ещё сотню пакетов через много-много роутеров. Вся сетка толькор и будет заниматься тем, что пересылать друг другу сертификаты.
Плюс не забываем про всякие NAT и прочие туннельные протоколы, когда роутер "подправляет" пакет на ходу. Ему надо будет переподписывать каждый такой пакет.
На всякий случай напомню, что инфраструктура TLS минимизирует трафик благодаря тому, что весь дорогостоящий handshake выполняется однократно на соединение, а не на каждый пакет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
