Плохо тем, что обычному пользователю — это uber ) Увы. Надеюсь со временем, такие вещи будут рассказывать в школе на уроках информатики вместо изучения Word. Не на уровне математики, которая задействована в ассиметричном шифровании, а на уровне концепций (Алиса, Боб, Ева, одностороннее преобразование и т.д.) хотя бы. Сейчас с этим всё грустно: в лучшем случае определение зеленой и красной строки ссылки в браузере.
Не поверите, но у меня так ругался роутер LinkSys, пока я его не вылечил с помощью DD-WRT.
Но вообще, если эта сферическая IoT-железяка измеряет влажность в вашей квартире, то, наверное, особой нужды закрывать её TLS'ом нет. А вот тем, чтобы её не убили детишки-какеры, если вам важно знать влажность, находясь за пределами квартиры, озаботиться всегда полезно.
> получаем необходимость домашнего доверенного центра сертификации…
> Двусмысленностей в работе чистого нат намного меньше, чем в фаерволе. Нат он примерно одинаковый для всех, а вот фаерволы бывают очень разные с разной логикой функционирования.
А вы, батенька, давно сидели за «чистым» натом? Подозреваю, что за чистым натом и без UPnP не работала бы и половина достойных применения протоколов. Взять хотя бы SIP и IPsec — первое, что всплывает в голове. Вот уж NAT — действительно то место, где созданные проблемы были героически решены.
Перед праздниками было два поста про то, что D-Link со штатной прошивкой и в хвост, и в гриву имели. Уверен, что D-Link не исключение. О какой вы там безопасности с IPv6? ))
> Т.е. чтобы решить проблему безопасности её надо создать?
Я бы сказал более общо: «чтобы решить проблему её надо создать». И это правда для всего )
> Устройства IoT бывают очень примитивными. Например датчики температуры. Зачем, если можно защитить периметр сети.
Я не слежу за IPv6 особенно, но когда я этим интересовался, там были LinkLocal адреса. Разве нельзя их использовать для таких устройств, если их не отменили?
> Надо туда SSL впихивать, сертификаты и т.п. менять?
В принципе, если там реализован Web, то сделать TLS — это уже вобщем-то не такая уж сложная задача.
Когда-то компьютер можно было убить пингом. Переход на ipv6 просто обострит проблему безопасности и подтолкнет к ее купированию, что в любом случае полезно, ибо сейчас некоторые производители вещей для интернет наплевательски относятся к этим вопросам, полагая, что 99% юзеров будут юзать их за натом
Под прозрачностью я имел ввиду прозрачность для юзера: чтобы для работы с ГОСТом не требовалось специальным образом собранных браузеров, целой тьмы плагинов и так далее. Именно так это выглядит сейчас. Сейчас юзеры Хрома начнут верещать, что у них перестали работать эти плагины, т.к. в 42-й версии гугл отключил по-умолчанию поддержку плагинов через API Mozilla. А скоро выпилит её совсем.
> методические рекомендации открыты
Ну на сайте ТК-26 они только на русском. Это не серьезно.
> ТК26 взаимодействует с IANA, которая взаимодействует с IETF
Черновику им. Чудова уже седьмой год. С тех пор никаких подвижек и даже попыток.
> ситуация может измениться с принятием нового стандарта на шифрование
Пока это даже у нас не стандарт.
На носу принятие нового браузерного API www.w3.org/TR/WebCryptoAPI. Про ГОСТ там тоже ничего не слышно. Хотя, казалось бы, это отличное решение для того, чтобы похоронить эту бешенную армию плагинов.
Стандартизацией TLS занимается TLS WG. ТК-26 стандартизует какой-то свой TLS с ГОСТом, блэкджеком и дамами, потому что в TLS WG об этом ни слуху, ни духу. А именно отсутствием работы c TLS WG объясняется полное отсутствие поддержи ГОСТов в известных реализациях TLS, отсутствия поддержки в браузерах и существование таких вот уродов. И использование ГОСТа никогда не станет массовым, пока его поддержка не будет прозрачной.
Out of context вы правы, но мы здесь ведем дискуссию о примитивных типах.
Но если вы хотите поговорить о высоком, то ежели оператор деления переопределен, то компилятору вообще нет нужды думать о том, как это деление оптимизировать: достаточно вызвать тело переопределенного оператора, а следовательно и на диапазон возможных значений можно забить болт. Но в конечном итоге всё, так или иначе, сведется к действиям над элементарными типами. И если там будет уже настоящее целочисленное деление на константу, то мы опять вернемся сюда.
> То же самое — сюрприз-сюрприз! — произойдёт и с предложенным мной кодом, компилятор точно так же рассчитает subradius и запишет его числом, а не выражением.
В том-то и дело, что когда это делает компилятор, он делает это для разных констант немного по-разному. Я вам уже в третий раз пишу об этом, а вы всё ленитесь почитать каменты выше. Для разных констант существуют разные варианты. В частности, выше показано, что если делитель будет равен 1023, то ваш код будет работать, не так, как если бы Вы производили деление.
> > Однако в вашем случае без дополнительных мер, возможна потеря точности для некоторых значений делителей.
> А в вашем, будто, нет.
В нашем, это в каком? Когда это делает компилятор? Не будто, а 100% нет.
> Достаточно того, чтобы происходило два или более деления на одно и то же число.
Вы кажется читаете не внимательно. Я писал только об однократном делении. А о многократном я написал, что эффект будет.
Вы немного путаете тёплое с мягким. Поделить 1 без утраты точности на произвольное целое число действительно нельзя. Однако оптимизировать без потери точности целочисленное деление с остатком заменой на умножение и сдвиг(и) можно.
Если вы производите деление много-много раз, то безусловно такой выигрыш будет. Однако в вашем случае без дополнительных мер, возможна потеря точности для некоторых значений делителей.
В статье же описан код, сгенерированный реальным компилятором для однократного деления на целочисленную константу. Если бы делитель не был известной константой, то любые подобные оптимизации не дали бы никакого выигрыша. Хоть ручные, хоть автоматические.
В примере в статье компилятор делает оптимизацию без утраты точности. Более того, в каментах уважаемый Mrrl показал, что не всё так тупо и линейно и ваши две строчки кода будут работать не всегда эквивалентно целочисленному делению.
Какая-то Microsoft'овская идеалогия. Debian после релиза не устраняет же баги, кроме секьюрных. Поэтому стабильность от того, что вы подождете 8.1 не возрастёт.
Не поверите, но у меня так ругался роутер LinkSys, пока я его не вылечил с помощью DD-WRT.
Но вообще, если эта сферическая IoT-железяка измеряет влажность в вашей квартире, то, наверное, особой нужды закрывать её TLS'ом нет. А вот тем, чтобы её не убили детишки-какеры, если вам важно знать влажность, находясь за пределами квартиры, озаботиться всегда полезно.
> получаем необходимость домашнего доверенного центра сертификации…
А у вас его ещё нету?! :-o
А вы, батенька, давно сидели за «чистым» натом? Подозреваю, что за чистым натом и без UPnP не работала бы и половина достойных применения протоколов. Взять хотя бы SIP и IPsec — первое, что всплывает в голове. Вот уж NAT — действительно то место, где созданные проблемы были героически решены.
Я бы сказал более общо: «чтобы решить проблему её надо создать». И это правда для всего )
> Устройства IoT бывают очень примитивными. Например датчики температуры. Зачем, если можно защитить периметр сети.
Я не слежу за IPv6 особенно, но когда я этим интересовался, там были LinkLocal адреса. Разве нельзя их использовать для таких устройств, если их не отменили?
> Надо туда SSL впихивать, сертификаты и т.п. менять?
В принципе, если там реализован Web, то сделать TLS — это уже вобщем-то не такая уж сложная задача.
Под прозрачностью я имел ввиду прозрачность для юзера: чтобы для работы с ГОСТом не требовалось специальным образом собранных браузеров, целой тьмы плагинов и так далее. Именно так это выглядит сейчас. Сейчас юзеры Хрома начнут верещать, что у них перестали работать эти плагины, т.к. в 42-й версии гугл отключил по-умолчанию поддержку плагинов через API Mozilla. А скоро выпилит её совсем.
> методические рекомендации открыты
Ну на сайте ТК-26 они только на русском. Это не серьезно.
> ТК26 взаимодействует с IANA, которая взаимодействует с IETF
Черновику им. Чудова уже седьмой год. С тех пор никаких подвижек и даже попыток.
> ситуация может измениться с принятием нового стандарта на шифрование
Пока это даже у нас не стандарт.
На носу принятие нового браузерного API www.w3.org/TR/WebCryptoAPI. Про ГОСТ там тоже ничего не слышно. Хотя, казалось бы, это отличное решение для того, чтобы похоронить эту бешенную армию плагинов.
Но если вы хотите поговорить о высоком, то ежели оператор деления переопределен, то компилятору вообще нет нужды думать о том, как это деление оптимизировать: достаточно вызвать тело переопределенного оператора, а следовательно и на диапазон возможных значений можно забить болт. Но в конечном итоге всё, так или иначе, сведется к действиям над элементарными типами. И если там будет уже настоящее целочисленное деление на константу, то мы опять вернемся сюда.
Устанавливать один пароль не имеет смысла, если его знает дилер, то читай его знают все заинтересованные.
Казалось бы, откуда бы компилятору статически типизированного языка, узнать диапазон возможных значений переменной?
В том-то и дело, что когда это делает компилятор, он делает это для разных констант немного по-разному. Я вам уже в третий раз пишу об этом, а вы всё ленитесь почитать каменты выше. Для разных констант существуют разные варианты. В частности, выше показано, что если делитель будет равен 1023, то ваш код будет работать, не так, как если бы Вы производили деление.
> > Однако в вашем случае без дополнительных мер, возможна потеря точности для некоторых значений делителей.
> А в вашем, будто, нет.
В нашем, это в каком? Когда это делает компилятор? Не будто, а 100% нет.
> Достаточно того, чтобы происходило два или более деления на одно и то же число.
Вы кажется читаете не внимательно. Я писал только об однократном делении. А о многократном я написал, что эффект будет.
В статье же описан код, сгенерированный реальным компилятором для однократного деления на целочисленную константу. Если бы делитель не был известной константой, то любые подобные оптимизации не дали бы никакого выигрыша. Хоть ручные, хоть автоматические.
Вы предлагаете оптимизорвать целочисленное деление, через деление даблов?