Есть свой протокол UDP based, хочу через него передавать RSA public key + кое какая инфа подписанная RSA private key. RSA public key будет передаваться в der формате. вот его дамп
Канал передачи данных, по которому передается ключ, не шифрованный. Вопрос: это нормально вообще передавать в таком формате RSA public key? Я имею ввиду сам DER формат, заголовок + то что в конце стоит public exponent (это не секюрная ведь инфа экспонента)? Или все таки надо извлечь из DER 2048 bit RSA public key и передавать только его? Если надо извлечь ключ из DER то делает ли это OpenSSL, т.к я нашел тока DER
Здравствуйте, Srv, Вы писали:
Srv> Вопрос: это нормально вообще передавать в таком формате RSA public key?
Публичный можно передавать как угодно и кому угодно. На то он и публичный. Хотя, лучше оборачивать его в один из стандартных форматов и передавать соответствующим файлом. Правило хорошего тона.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Srv, Вы писали:
Srv>> Вопрос: это нормально вообще передавать в таком формате RSA public key?
S>Публичный можно передавать как угодно и кому угодно. На то он и публичный. Хотя, лучше оборачивать его в один из стандартных форматов и передавать соответствующим файлом. Правило хорошего тона.
Спасибо за ответ )
Да про файлы знаю, но у меня еще стоит задача сэкономить payload внутри пакета. Вот и не пойму стоит извлекать DER или нет. Если его извлекать то парсер видимо придется свой прикручивать.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Srv, Вы писали:
S> Вот и не пойму стоит извлекать DER или нет. Если его извлекать то парсер видимо придется свой прикручивать.
S>Потрошить DER чтоб сэкономить пару байт для payload? Чем Вы там занимаетесь?
Открою еще один секрет, это UDP discovery пакет, который посылается раз в 5 секунд, общая длина выходит 570 байт, не охото сильно нагружать сеть.
Возможно стоит передавать подписанные сообщения + хеш ключа (или любой идентификатор). Какой вам смысл передавать открытый ключ? Открытый ключ у получающей стороны и так должен быть, иначе как она проверит, что это нужный ключ?
Srv>Открою еще один секрет, это UDP discovery пакет, который посылается раз в 5 секунд, общая длина выходит 570 байт, не охото сильно нагружать сеть.
Как понял Вы хотите потрошить DER, чтоб отправлять только его Contents? Если так, то сколько там байт сэкономить удасться? Два, может три-четрые. Не густо. К тому же 570B сейчас вообще ни о чём не только раз в пять секунд, но в доли секунды. На современных сетях. Или у Вас там что-то древнее?
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Srv, Вы писали:
Srv>>Открою еще один секрет, это UDP discovery пакет, который посылается раз в 5 секунд, общая длина выходит 570 байт, не охото сильно нагружать сеть.
S>Как понял Вы хотите потрошить DER, чтоб отправлять только его Contents? Если так, то сколько там байт сэкономить удасться? Два, может три-четрые. Не густо. К тому же 570B сейчас вообще ни о чём не только раз в пять секунд, но в доли секунды. На современных сетях. Или у Вас там что-то древнее?
Спасибо за интерес )
У нас обычный WiFi в нем UDP broadcast discovery с этим вот пакетом в 570 байт. Да хотелось бы отправлять DER Contents, но целесообразно ли это? Экономится 14 байт.
Само собой разумеется что клиентов с этим UDP broadcast discovery в одной сети может быть много, ну скажем до 100.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Srv, Вы писали:
>>Экономится 14 байт.
S>Откуда 14B? Там identifier-1B, и lenght 2-4 B в definite form для размера ключа.
Собственно сам ключ 2048 бит (256 байт), на сколько я понимаю остальное это DER. На выходе 270 байт DER.
Здравствуйте, Srv, Вы писали:
Srv>Здравствуйте, smeeld, Вы писали:
S>>Здравствуйте, Srv, Вы писали:
>>>Экономится 14 байт.
S>>Откуда 14B? Там identifier-1B, и lenght 2-4 B в definite form для размера ключа. Srv>Собственно сам ключ 2048 бит (256 байт), на сколько я понимаю остальное это DER. На выходе 270 байт DER. Длина ключа у меня будет постоянной.
Здравствуйте, Srv, Вы писали:
Srv>Открою еще один секрет, это UDP discovery пакет, который посылается раз в 5 секунд
Зачем так часто? Неужели окружение сети меняется столь стремительно?
Представьте хотя бы сотню-другую таких клиентов, орущих в сеть каждые 5 секунд — Вы действительно хотите весь этот трафик? Тот же UPnP discovery происходит куда реже.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Srv, Вы писали:
Srv>>Открою еще один секрет, это UDP discovery пакет, который посылается раз в 5 секунд
MD>Зачем так часто? Неужели окружение сети меняется столь стремительно? MD>Представьте хотя бы сотню-другую таких клиентов, орущих в сеть каждые 5 секунд — Вы действительно хотите весь этот трафик? Тот же UPnP discovery происходит куда реже.
Дак вот я и думаю как бы пооптимизировать тут... 5 секунд это не так часто. Задача стоит чтобы как можно быстрее обнаружить друг друга.
Srv>Канал передачи данных, по которому передается ключ, не шифрованный. Вопрос: это нормально вообще передавать в таком формате RSA public key? Я имею ввиду сам DER формат, заголовок + то что в конце стоит public exponent (это не секюрная ведь инфа экспонента)? Или все таки надо извлечь из DER 2048 bit RSA public key и передавать только его? Если надо извлечь ключ из DER то делает ли это OpenSSL, т.к я нашел тока DER
Нормально было бы передавать весь сертификат целиком, он кроме публичного ключа содержит и всякую другую полезную информацию (типа, кем выдан, кому выдан и т.п.). Причем подписана в нем вся эта информация, а не только публичный ключ.
Только более-менее секурные RSA сертификаты довольно большие, в один UDP пакет могут и не полезть. Я бы посоветовал посмотреть на Elliptic Curves (ECDSA, если мы говорим именно о сертификатах для подписи). Они гораздо компактнее, чем RSA-сертификаты той же степени защищенности. И при этом многие операции с ними выполнаются в разы быстрее. OpenSSL их умеет.
Еще бы я посоветовал не выпендриваться со своим протоколом, а взять DTLS. Потому что если вы не знаете, чти такое public exponent, это говорит о вашем низком уровне криптографической образованности. А это значит, что вы наделаете СТОЛЬКО ошибок, что с точки зрения криптоаналитика ваш протокол мало чем будет отличаться от передачи данных открытын текстом и без подписи.
Здравствуйте, Srv, Вы писали:
Srv>Открою еще один секрет, это UDP discovery пакет, который посылается раз в 5 секунд, общая длина выходит 570 байт, не охото сильно нагружать сеть.
Сети более-менее все равно, какого размера пакет вы посылаете в пределах MTU. Но вот более-менее защищенный (с числом бит хотя бы 2048) RSA сертификат вы в 570 байт не впихнете.
Здравствуйте, Srv, Вы писали:
Srv>У нас обычный WiFi в нем UDP broadcast discovery с этим вот пакетом в 570 байт. Да хотелось бы отправлять DER Contents, но целесообразно ли это? Экономится 14 байт. Srv>Само собой разумеется что клиентов с этим UDP broadcast discovery в одной сети может быть много, ну скажем до 100.
У вас точка доступа струячит какого-то сравнимого размера пакеты 10 раз в секунду. Beacons называются. Не берите в голову.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Зачем так часто? Неужели окружение сети меняется столь стремительно? MD>Представьте хотя бы сотню-другую таких клиентов, орущих в сеть каждые 5 секунд — Вы действительно хотите весь этот трафик? Тот же UPnP discovery происходит куда реже.
Но он и думает очень долго. А сотня-другая клиентов в wifi сети вокруг одной точки доступа вряд ли уживется.
Здравствуйте, Pzz, Вы писали:
Srv>>Канал передачи данных, по которому передается ключ, не шифрованный. Вопрос: это нормально вообще передавать в таком формате RSA public key? Я имею ввиду сам DER формат, заголовок + то что в конце стоит public exponent (это не секюрная ведь инфа экспонента)? Или все таки надо извлечь из DER 2048 bit RSA public key и передавать только его? Если надо извлечь ключ из DER то делает ли это OpenSSL, т.к я нашел тока DER
Pzz>Нормально было бы передавать весь сертификат целиком, он кроме публичного ключа содержит и всякую другую полезную информацию (типа, кем выдан, кому выдан и т.п.). Причем подписана в нем вся эта информация, а не только публичный ключ.
Pzz>Только более-менее секурные RSA сертификаты довольно большие, в один UDP пакет могут и не полезть. Я бы посоветовал посмотреть на Elliptic Curves (ECDSA, если мы говорим именно о сертификатах для подписи). Они гораздо компактнее, чем RSA-сертификаты той же степени защищенности. И при этом многие операции с ними выполнаются в разы быстрее. OpenSSL их умеет.
Pzz>Еще бы я посоветовал не выпендриваться со своим протоколом, а взять DTLS. Потому что если вы не знаете, чти такое public exponent, это говорит о вашем низком уровне криптографической образованности. А это значит, что вы наделаете СТОЛЬКО ошибок, что с точки зрения криптоаналитика ваш протокол мало чем будет отличаться от передачи данных открытын текстом и без подписи.
Спасибо за ответ.
Да в криптографии не так давно, каюсь. DTLS все хочу посмотреть, но не было время, теперь обязательно загляну. Если честно то я не совсем понимаю какие можно наделать ошибки в схеме: передача Public Key от клиента0 к клиенту1, затем энкрипшен этим Public Key у клиента1, передача пакета обратно клиенту0 и расшифровка пакета через Private key. Естественно всякие challenge и прочие штучки с передачей только hash, а не самого значения я учел.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Srv, Вы писали:
Srv>>У нас обычный WiFi в нем UDP broadcast discovery с этим вот пакетом в 570 байт. Да хотелось бы отправлять DER Contents, но целесообразно ли это? Экономится 14 байт. Srv>>Само собой разумеется что клиентов с этим UDP broadcast discovery в одной сети может быть много, ну скажем до 100.
Pzz>У вас точка доступа струячит какого-то сравнимого размера пакеты 10 раз в секунду. Beacons называются. Не берите в голову.
Размер beacon не сильно помню, приходилось переписывать madwifi драйвера )
Здравствуйте, 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 (как один из вариантов размер зависит от количества рестрансляций).
