Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Можно ли чисто теоретически обеспечить электронной подписью из белого списка каждый передаваемый сетевой пакет?
Размер непосредственно 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 выполняется однократно на соединение, а не на каждый пакет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
