Здравствуйте, Srv, Вы писали:
Srv>Есть свой протокол UDP based, хочу через него передавать RSA public key + кое какая инфа подписанная RSA private key. RSA public key будет передаваться в der формате. вот его дамп
Передавать вполне нормально. Но стоит помнить, что в стандартный MTU влезет ключ только в 1024 бит, что уже считается достаточно слабым размером.
Рекомендую взять эллиптический ключ, лучше всего https://ed25519.cr.yp.to/ — размер ключа будет всего 32 байта, так что можно передавать без особых волнений о размерах.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Srv, Вы писали:
Srv>>Открою еще один секрет, это UDP discovery пакет, который посылается раз в 5 секунд, общая длина выходит 570 байт, не охото сильно нагружать сеть.
Pzz>Сети более-менее все равно, какого размера пакет вы посылаете в пределах MTU.
Я так понял что нагрузка на маршрутизатор возрастает когда он начинает фрагментировать пакеты.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Srv, Вы писали:
Srv>>Есть свой протокол UDP based, хочу через него передавать RSA public key + кое какая инфа подписанная RSA private key. RSA public key будет передаваться в der формате. вот его дамп C>Передавать вполне нормально. Но стоит помнить, что в стандартный MTU влезет ключ только в 1024 бит, что уже считается достаточно слабым размером.
C>Рекомендую взять эллиптический ключ, лучше всего https://ed25519.cr.yp.to/ — размер ключа будет всего 32 байта, так что можно передавать без особых волнений о размерах.
Спасибо за ссылку. Там версия 20110221, я так понимаю проект сейчас не поддерживается?
Здравствуйте, vsb, Вы писали:
vsb>Возможно стоит передавать подписанные сообщения + хеш ключа (или любой идентификатор). Какой вам смысл передавать открытый ключ? Открытый ключ у получающей стороны и так должен быть, иначе как она проверит, что это нужный ключ?
Дело в том что я всегда генерирую пару Public key/Private key когда происходит запуск системы. То есть время жизни пары ключей это одна сессия, а сессия это пока жив сетевой интерфейс.
Здравствуйте, Srv, Вы писали:
vsb>>Возможно стоит передавать подписанные сообщения + хеш ключа (или любой идентификатор). Какой вам смысл передавать открытый ключ? Открытый ключ у получающей стороны и так должен быть, иначе как она проверит, что это нужный ключ? Srv>Дело в том что я всегда генерирую пару Public key/Private key когда происходит запуск системы. То есть время жизни пары ключей это одна сессия, а сессия это пока жив сетевой интерфейс.
Как принимающая сторона узнает, что это ваш ключ, а не злоумышленника? Представьте себе, что в вашей сети завёлся злоумышленник, так же сгенерировал себе ключи и также посылает пакеты. Как вы отличите правильные пакеты от неправильных?
Здравствуйте, Srv, Вы писали:
C>>Рекомендую взять эллиптический ключ, лучше всего https://ed25519.cr.yp.to/ — размер ключа будет всего 32 байта, так что можно передавать без особых волнений о размерах. Srv>Спасибо за ссылку. Там версия 20110221, я так понимаю проект сейчас не поддерживается?
Поддерживается. Просто с 2011-го в реализации на сайте автора не было найдено никаких проблем.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Srv, Вы писали:
vsb>>>Возможно стоит передавать подписанные сообщения + хеш ключа (или любой идентификатор). Какой вам смысл передавать открытый ключ? Открытый ключ у получающей стороны и так должен быть, иначе как она проверит, что это нужный ключ? Srv>>Дело в том что я всегда генерирую пару Public key/Private key когда происходит запуск системы. То есть время жизни пары ключей это одна сессия, а сессия это пока жив сетевой интерфейс.
vsb>Как принимающая сторона узнает, что это ваш ключ, а не злоумышленника? Представьте себе, что в вашей сети завёлся злоумышленник, так же сгенерировал себе ключи и также посылает пакеты. Как вы отличите правильные пакеты от неправильных?
Хороший вопрос. Злоумышленник должен знать формат и алгоритм формирования ответного пакета который шифруется public key и расшифровывается на другой стороне private key. На самом деле можно конечно узнать формат и алгоритм формирования, но мне кажется это одно и тоже что и хранить private key вшитый в программу (поправьте меня если я не прав). Мне еще надо как-то развивать версии и необходимо чтобы старые клиенты поддерживались новыми.
Здравствуйте, Srv, Вы писали:
Srv>Хороший вопрос. Злоумышленник должен знать формат и алгоритм формирования ответного пакета который шифруется public key и расшифровывается на другой стороне private key. На самом деле можно конечно узнать формат и алгоритм формирования, но мне кажется это одно и тоже что и хранить private key вшитый в программу (поправьте меня если я не прав). Мне еще надо как-то развивать версии и необходимо чтобы старые клиенты поддерживались новыми.
Это называется security through obscurity и даёт это мнимую безопасность. Вам вероятно нужно либо заранее сгенерировать все ключи и прописать публичные ключи в нужных местах, тогда их можно и не передавать, а передавать более короткий идентификатор, по которому адресат поймёт, какой ключ был использован; либо организовать доверенный центр и подписывать ключи одним известным ключом (проще всего просто взять готовые стандарты вроде X.509).
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Srv, Вы писали:
Srv>>Хороший вопрос. Злоумышленник должен знать формат и алгоритм формирования ответного пакета который шифруется public key и расшифровывается на другой стороне private key. На самом деле можно конечно узнать формат и алгоритм формирования, но мне кажется это одно и тоже что и хранить private key вшитый в программу (поправьте меня если я не прав). Мне еще надо как-то развивать версии и необходимо чтобы старые клиенты поддерживались новыми.
vsb>Это называется security through obscurity и даёт это мнимую безопасность. Вам вероятно нужно либо заранее сгенерировать все ключи и прописать публичные ключи в нужных местах, тогда их можно и не передавать, а передавать более короткий идентификатор, по которому адресат поймёт, какой ключ был использован; либо организовать доверенный центр и подписывать ключи одним известным ключом (проще всего просто взять готовые стандарты вроде X.509).
Согласен да что нужен какой-то trusted центр которому все доверяют, но система не предполагает его наличия и я бы не хотел что-то усложнять. Кроме того hash значения формируемые в digest пакете тоже создаются по определенному алгоритму, ясно что это не решает проблему, но...
Здравствуйте, Srv, Вы писали:
Srv>Я так понял что нагрузка на маршрутизатор возрастает когда он начинает фрагментировать пакеты.
Это сложный вопрос. Во-первых, насколько я понимаю, речь идет не о маршрутизаторе (устройстве, которое организует связь между разными IP-сетями), а о точке доступа. Современные точки доступа (те, которые 150/300/и т.д. мегабит) скорее стараются не фрагментировать пакет, а послать несколько "логических" пакетов одним "физическим". Потому что в wifi дырка между пакетами очень большая, и заполучив право передавать в эфир, лучше отработать его по полной.
Во-вторых, фрагментировать там будет скорее передающая машина. "Натифный" MTU wifi — что-то около 2.5К (точно не помню), но для операционной системы wifi выглядит, как Ethernet с его MTU 1.5K
Pzz>Во-вторых, фрагментировать там будет скорее передающая машина. "Натифный" MTU wifi — что-то около 2.5К (точно не помню), но для операционной системы wifi выглядит, как Ethernet с его MTU 1.5K
WiFi такой же как и в Ethernet.
Но он аггрегириует кучу пакетов в один физический, если может. И в зависимости от того какой метод выбран и какой именно стандарт 11n или 11ac, это будет от максимум нескольких килобайт до насколько я помню мегабайта.
Ну и предсказать сколько он будет выплевывать за раз нереально. И от размера пакетов, и от peer зависит, и от алгоритмов firmware (как один из вариантов размер зависит от количества рестрансляций).
Здравствуйте, gardener, Вы писали:
G>WiFi такой же как и в Ethernet.
У "оригинального" wifi (того, который еще не 11n и не 11ac) максимальный MTU был определен, как 2304 байта. Другой вопрос, что его обычно используют в связке с Ethernet, и предполагается, что пакеты могут свободно перебрасываться точкой доступа между проводом и эфиром. Поэтому на практике использовать пакеты размером больше 1500 байт не получается.
G>Но он аггрегириует кучу пакетов в один физический, если может. И в зависимости от того какой метод выбран и какой именно стандарт 11n или 11ac, это будет от максимум нескольких килобайт до насколько я помню мегабайта. G>Ну и предсказать сколько он будет выплевывать за раз нереально. И от размера пакетов, и от peer зависит, и от алгоритмов firmware (как один из вариантов размер зависит от количества рестрансляций).
