Просто довольно странно предлагать такое решение, когда основной тезис статьи - "любой самый стойкий криптографический протокол можно запороть корреляцией запросов".
Такое может сработать в идеальной стране с розовыми понями, но не в России.
Я вам даже больше скажу. Юридически нет никакого запрета вам взмахнуть крыльями (ну или руками) и полететь. Так что нет никакой проблемы для людей летать.
Передергиваю? Разумеется. Но не я первый начал. По крайней мере в отсутствии юридического запрета летать, махая руками, я точно уверен. А вот в том, что Apple не подаст на вас в суд по какому-нибудь копирастическому закону за взлом iPhone - я вот совсем не уверен.
Если бы эппл заботились о безопасности юзеров, как они заявляют, и ни в коем случае не строили бы свой уютный вендор-лок, то там бы была кнопочка "Разблокировать загрузчик", как на Android, которая бы, пусть даже, выводила бы 72 кеглем красным мигающим цветом "ДАЛЕЕ НЕБЕЗОПАСНО", снимала бы гарантию, снимала бы с Эппла массу ответственности, отрубало бы Apple Pay, но загрузчик бы таки разблокировало. И аналогичная процедура с 72 красным цветом, но для установки сторонних приложений, с меньшими деструктивными последствиями.
А поскольку ничего этого не наблюдается и не наблюдалось раньше, мы делаем вывод, что вот это вот имеет такое же отношение к заботе о безопасности пользователя, какое имеет блокировка интернета к заботе о безопасности детей. Иначе говоря, "в гараж" -- предлог, а наблюдается обычный vendor lock-in.
То, что загрузчик айфона, намертво зашитый в ROM процессора айфона, принимает только софт, подписанный приватными ключами Apple, да еще и c anti-rollback - это явный и прямой запрет ставить что-то, кроме последней версии софта Apple.
Не, разумеется, можно поменять процессор, а в качестве зависимостей - переразвести плату, поставить другой сотовый модем, написать другой софт и так далее - но к установке софта на айфон это не будет иметь абсолютно никакого отношения.
Не очень уверен, что автор получил шумы именно радиоактивного распада, а не шумы схемы или наводки из эфира, например. Думаю, что взять счетчик гейгера и измерять время между импульсами было бы надежнее в том плане, что сильно уменьшается шанс получить вместо рандома текущую передачу "Радио Маяк".
Это, к слову, обычный modInverse (первые два) и (2^32 / 10) + 1 (третий, потому что 10 нельзя обратить по модулю 2^32, как в первых двух). Так всю алгебру конечных полей закопирайтить можно.
Есть ли смысл в ревакцинации векторными вакцинами? Не будет ли вирус-носитель (на который, я полагаю, тоже будет выработан иммунитет) сожран еще на подходе, так и не успев ничего сделать?
Тут больше претензия в том, что на выходе вместо модульных частей получается монолит, который хорош только в том, подо что его затачивали.
Да, разумеется, слоистое решение не идеал в плане эффективности. После DTLS можно не делать SCTP-хендшейк, например, а сразу инициализировать протокол каким-то состоянием. Насчет миграции, кстати, не согласен. DTLS в такое должен уметь, если правильно написать UDP-слой. Но это можно дорабатывать, сохраняя модульность. Заодно и реализации этих протоколов нормальные появятся, а не, упаси господи, usrsctp. Еще я с некоторым подозрением смотрю на попытку переизобрести TLS. Понятно, что там учтен опыт нахождения дырок в оном, но все же.
А пока, как я понял, на выходе получается вишмастер, который можно воткнуть, если приложению нужно мультипоточное надежное соединение. А если нужно чуть другое — уже нельзя.
Ну, теоретически можно было бы взять стек UDP/DTLS/SCTP/протокол приложения сверху.
DTLS шифрует пакеты SCTP, SCTP мультиплексирует потоки и обеспечивает надежную доставку (не страдая при этом проблемами TCP, когда один пропавший пакет тормозит всю очередь). Или не обеспечивает, если конкретно этому потоку такая доставка не нужна и он прекрасно живет с потерями. Или обеспечивает со стратегией "если за секунду пакет не ушел — выкидываем". Там много настроек.
Приложение работает уже поверх SCTP с абстракцией "много надежных зашифрованных потоков". Но у этого стека есть фатальный недостаток.
Ну, тот же MELPe 2400/1200/600 бит/с существует с лохматых годов, и в целом дает вполне неплохое качество звука. При этом работает на микроконтроллерах лохматых годов, не требуя генеративных моделей.
При этом вроде были сообщения, что "нейронные" кодеки могут "додумывать" и менять близкие по звучанию слова. Так что мне кажется, что куда-то не туда разработка кодеков повернула.
Может. Только не в роли метки, а просто устройства-клиента, протокол там произвольный. Для этого подойдет такой ридер, как у автора, и не подойдут самые простые, которые только Mifare (обычно именно они присутствуют во всяких ардуино-наборах всё-в-одном).
В телефоне, разумеется, можно реализовать любую криптографию, которую только удастся придумать. С метками, например, такое проблематичнее. Но тоже можно, при желании можно сделать карточку, которая будет через AES/RSA/ECDSA аутентифицироваться.
Миллисекунд достаточно. SDR приёмник пишет кусок спектра на диск.
Как человек, который писал SDR-приемником кусок спектра на диск, и получал на выходе 5 гигабайт за две минуты (полоса 20 мегагерц) очень сомневаюсь, что такие приемники можно массово развернуть, а тем более хранить какую-то историю. Один день такой записи займет 3.5 терабайта, а это лишь маленький участок спектра, а спектр-то огромный.
Третий и самый сложный подход – продолжать использовать альтернативную сборку ОС, но заблокировать загрузчик используя user-settable root of trust. Это действительно сложный и затратный подход, достойный написания отдельной статьи, потому как требует самостоятельно делать сборку ОС и самостоятельно её подписывать.
Пишите обязательно. Рут использую как минимум для файрвола (очень удобно срезать рекламу в тех местах, где доступ в интернет не предполагается в принципе, например в оффлайн-играх). Риски, связанные с открытием загрузчика (и наличием рекавери, которое смотрит в мир голым задом), в принципе понимал с самого начала, и принимал как неизбежное зло. Так что возможность закрыть загрузчик обратно со своими ключами была бы кстати.
Это, скажем так, сводит всю затею к "злоумышленнику будет лень ковырять", т.е. security via obscurity.
Думаю в случае с valve или любой другой крупной компании государев mitm уже заранее будет сконфигурирован как надо. А неуловимые Джо — они и в Африке такие. И никакой WASM не защищает от скрипта, который просто повесит глобальный хук на onkeydown. Ну и если у вас в канале сидит MITM — очевидно, он может предоставляться тем же IP, что и у клиента.
Если злобный прокси может слушать канал — то он может его и менять. Ничего не мешает просто отдать клиенту немного другую версию скрипта шифрования, который чисто случайно помимо основной задачи ещё сбросит на нужный сервер нешифрованную версию пароля.
Это именно та причина, почему если нет доверенного TLS, то последующие пляски с шифрованием полная фикция — через такой прокси троянов можно прямо в страницу напихать. Не говоря уже о том, что даже после вот этого очень шифрованного логина сессионная кука начинает летать открытым текстом
Ну да, если будет не 24 килобита, а, например, 64 - то это сильно изменит ситуацию и, в целом, будет полным провалом прогноза.
Говорят, что самый интересный дворец все же был защищен по наземному периметру, а вот на береговую линию защиту поставить забыли.
Просто довольно странно предлагать такое решение, когда основной тезис статьи - "любой самый стойкий криптографический протокол можно запороть корреляцией запросов".
Такое может сработать в идеальной стране с розовыми понями, но не в России.
И все снова свелось к "я верю, что никто не будет вести логов".
Я вам даже больше скажу. Юридически нет никакого запрета вам взмахнуть крыльями (ну или руками) и полететь. Так что нет никакой проблемы для людей летать.
Передергиваю? Разумеется. Но не я первый начал. По крайней мере в отсутствии юридического запрета летать, махая руками, я точно уверен. А вот в том, что Apple не подаст на вас в суд по какому-нибудь копирастическому закону за взлом iPhone - я вот совсем не уверен.
Если бы эппл заботились о безопасности юзеров, как они заявляют, и ни в коем случае не строили бы свой уютный вендор-лок, то там бы была кнопочка "Разблокировать загрузчик", как на Android, которая бы, пусть даже, выводила бы 72 кеглем красным мигающим цветом "ДАЛЕЕ НЕБЕЗОПАСНО", снимала бы гарантию, снимала бы с Эппла массу ответственности, отрубало бы Apple Pay, но загрузчик бы таки разблокировало. И аналогичная процедура с 72 красным цветом, но для установки сторонних приложений, с меньшими деструктивными последствиями.
А поскольку ничего этого не наблюдается и не наблюдалось раньше, мы делаем вывод, что вот это вот имеет такое же отношение к заботе о безопасности пользователя, какое имеет блокировка интернета к заботе о безопасности детей. Иначе говоря, "в гараж" -- предлог, а наблюдается обычный vendor lock-in.
То, что загрузчик айфона, намертво зашитый в ROM процессора айфона, принимает только софт, подписанный приватными ключами Apple, да еще и c anti-rollback - это явный и прямой запрет ставить что-то, кроме последней версии софта Apple.
Не, разумеется, можно поменять процессор, а в качестве зависимостей - переразвести плату, поставить другой сотовый модем, написать другой софт и так далее - но к установке софта на айфон это не будет иметь абсолютно никакого отношения.
Проверка подписи в загрузчике запрещает. А сменить загрузчик запрещает то, что он находится в постоянной памяти прямо на процессоре.
А если нет, но ваш аккаунт кому-то очень нужен - то можно сходить на соответствующие ресурсы в даркнете и за пару тысяч рублей эту информацию узнать.
Не очень уверен, что автор получил шумы именно радиоактивного распада, а не шумы схемы или наводки из эфира, например. Думаю, что взять счетчик гейгера и измерять время между импульсами было бы надежнее в том плане, что сильно уменьшается шанс получить вместо рандома текущую передачу "Радио Маяк".
Это, к слову, обычный
modInverse(первые два) и(2^32 / 10) + 1(третий, потому что 10 нельзя обратить по модулю 2^32, как в первых двух). Так всю алгебру конечных полей закопирайтить можно.Есть ли смысл в ревакцинации векторными вакцинами? Не будет ли вирус-носитель (на который, я полагаю, тоже будет выработан иммунитет) сожран еще на подходе, так и не успев ничего сделать?
Тут больше претензия в том, что на выходе вместо модульных частей получается монолит, который хорош только в том, подо что его затачивали.
Да, разумеется, слоистое решение не идеал в плане эффективности. После DTLS можно не делать SCTP-хендшейк, например, а сразу инициализировать протокол каким-то состоянием. Насчет миграции, кстати, не согласен. DTLS в такое должен уметь, если правильно написать UDP-слой. Но это можно дорабатывать, сохраняя модульность. Заодно и реализации этих протоколов нормальные появятся, а не, упаси господи, usrsctp. Еще я с некоторым подозрением смотрю на попытку переизобрести TLS. Понятно, что там учтен опыт нахождения дырок в оном, но все же.
А пока, как я понял, на выходе получается вишмастер, который можно воткнуть, если приложению нужно мультипоточное надежное соединение. А если нужно чуть другое — уже нельзя.
Ну, теоретически можно было бы взять стек UDP/DTLS/SCTP/протокол приложения сверху.
DTLS шифрует пакеты SCTP, SCTP мультиплексирует потоки и обеспечивает надежную доставку (не страдая при этом проблемами TCP, когда один пропавший пакет тормозит всю очередь). Или не обеспечивает, если конкретно этому потоку такая доставка не нужна и он прекрасно живет с потерями. Или обеспечивает со стратегией "если за секунду пакет не ушел — выкидываем". Там много настроек.
Приложение работает уже поверх SCTP с абстракцией "много надежных зашифрованных потоков". Но у этого стека есть фатальный недостаток.
Ну, тот же MELPe 2400/1200/600 бит/с существует с лохматых годов, и в целом дает вполне неплохое качество звука. При этом работает на микроконтроллерах лохматых годов, не требуя генеративных моделей.
При этом вроде были сообщения, что "нейронные" кодеки могут "додумывать" и менять близкие по звучанию слова. Так что мне кажется, что куда-то не туда разработка кодеков повернула.
Может. Только не в роли метки, а просто устройства-клиента, протокол там произвольный. Для этого подойдет такой ридер, как у автора, и не подойдут самые простые, которые только Mifare (обычно именно они присутствуют во всяких ардуино-наборах всё-в-одном).
В телефоне, разумеется, можно реализовать любую криптографию, которую только удастся придумать. С метками, например, такое проблематичнее. Но тоже можно, при желании можно сделать карточку, которая будет через AES/RSA/ECDSA аутентифицироваться.
Как человек, который писал SDR-приемником кусок спектра на диск, и получал на выходе 5 гигабайт за две минуты (полоса 20 мегагерц) очень сомневаюсь, что такие приемники можно массово развернуть, а тем более хранить какую-то историю. Один день такой записи займет 3.5 терабайта, а это лишь маленький участок спектра, а спектр-то огромный.
Разве не будет решением загрузиться в (подписанный) рекавери и прошить обратно штатный образ ОС, не трогая данные?
Пишите обязательно. Рут использую как минимум для файрвола (очень удобно срезать рекламу в тех местах, где доступ в интернет не предполагается в принципе, например в оффлайн-играх). Риски, связанные с открытием загрузчика (и наличием рекавери, которое смотрит в мир голым задом), в принципе понимал с самого начала, и принимал как неизбежное зло. Так что возможность закрыть загрузчик обратно со своими ключами была бы кстати.
Это, скажем так, сводит всю затею к "злоумышленнику будет лень ковырять", т.е. security via obscurity.
Думаю в случае с valve или любой другой крупной компании государев mitm уже заранее будет сконфигурирован как надо. А неуловимые Джо — они и в Африке такие. И никакой WASM не защищает от скрипта, который просто повесит глобальный хук на onkeydown. Ну и если у вас в канале сидит MITM — очевидно, он может предоставляться тем же IP, что и у клиента.
Если злобный прокси может слушать канал — то он может его и менять. Ничего не мешает просто отдать клиенту немного другую версию скрипта шифрования, который чисто случайно помимо основной задачи ещё сбросит на нужный сервер нешифрованную версию пароля.
Это именно та причина, почему если нет доверенного TLS, то последующие пляски с шифрованием полная фикция — через такой прокси троянов можно прямо в страницу напихать. Не говоря уже о том, что даже после вот этого очень шифрованного логина сессионная кука начинает летать открытым текстом