Определенно меньше, достаточно лишь проанализировать одну диспач функцию, чтобы всё встало на места.
Здесь не очень очевидно. Речь же, разумеется, идёт не о том, чтобы анализировать руками — речь об автоматическом анализе. И там в одном случае нужно хешмап разворачивать, а в другом следить за указателем в данных. Но не суть — что то, что другое решаются.
Этот подход создаёт не больше трудностей (а то и меньше), чем виртуализация. По идее, хороший анализ девиртуализации спокойно может отменить все подобные приседания. Поэтому такой подход не масштабируется.
Если его пытаться масштабировать, то получится что-то в стиле vmprotect. То есть просто сделать виртуальную машину и транслировать код под эту вм. При этом, одна инструкция этой вм может делать весьма много действий. А чтобы масштабировать защиту, вм генерируется при каждой компиляции новая.
Да, но это же не имеет прямого отношения к шифрованию. Любой драйвер должен это учитывать, даже если он не занимается никаким шифрованием вовсе, разве не так?
Проблема не в ip. С достаточной прозрачностью доставки обновлений, делать таргетированные апдейты нельзя.
Впрочем, если брать условный дебиан, то, по идее, если скомпрометировать популярные зеркала то, по идее, можно попробовать отдать таргетированно другую информацию... Хотя достаточно сложные условия на атаку (Option, уловить момент обновления, уловить нужные зеркала и пр.).
В любом случае, на порядок сложнее, чем в браузере
Не уверен, что готов согласиться. Не помню точных подробностей (источник вроде вот этот документ), поэтому опишу по памяти. Для каждого раздела мастер ключ шифрования храниться в нескольких экземплярах. Некоторые из них зашифрованы паролем пользователя(что логично), однако другие зашифрованы ассиметричным образом. Для последних сделана приписка "you don't need these unless you are an apple employee".
Соответственно, напрашивается вывод, что владелец приватного ключа (то есть apple), может при желании расшифровать раздел без доступа к паролю пользователя. Что в целом логично, т.к. пользователи любят забывать пароли.
Апдейт с руткитом отправить не выйдет, т.к. не выйдет сделать таргетированный апдейт (он тогда прилетит всем...). Если уж таким заниматься, то нужен бэкдор, при том не в апдейте — а на постоянной основе.
Неточные инструменты тоже бывают полезными. Всякими фильтрами блума, или hyperloglog-ом вполне себе успешно пользуются. Ну и в целом, что ssd/had, что ram — штуки не шибко точные. Но ничего, пользуемся.
До релиза раст детектировал такие паники и выдавал именно что ошибку. Перед реализовать это превратили в линт, который к тому же был выключен. Видимо некоторое время назад этот линт сделали deny by default.
Но линт, на то и линт, что он распознает эти паники эвристиками. Поэтому иногда не очень хорошо срабатывает (например)
Вопрос не в том, чтобы убедиться что нет конкретной лазейки. Вопрос в том, что доказать отсутствие бэкдоров внешними методами — крайне проблематично.
А пока у меня маленький вопрос - а зачем это мне?
Не знаю. Если Вы хотите, чтобы Вашим приложением пользовались в качестве "приватного мессенджера" — то открыть прийдётся. Если же Ваша ЦА — обычные пользователи, которым просто нужен мессенжер (удобный, красивый, etc), то можете не открывать.
Если что, открытие исходников не означает отсутствие заработка. Можете рассмотреть разные модели монетизации.
Вопрос именно в том, что открытые исходники есть необходимый пререквизит к приватному мессенжеру. Если мы о реальной приватности, а не о маркетинге, конечно
Есть механизмы стеганографии по встраиванию бэкдора в криптографию. Например, можно к каждому шифрованному офферу прилагать метаинформацию, зашифрованную публичным ключом злоумышленика. Или в самом p2p соединении оставлять шифрованный блок.
Дальше продать эту информацию провайдерам/точкам обмена трафиком и профит. Ну или мониторить офферы и собирать информацию.
Или в другую сторону: а сколько по времени нужно производить эксперимент по мониторингу? Что если приложение выходит на связь только раз в сутки, в глубокую ночь?;)
И напомню, что всю процедуру проверки необходимо повторять после каждого обновления. С нуля, т.к. неизвестно что поменялось.
Короче говоря, нет. Закрытые исходники — это крест на доверии/приватности.
А стоит ли? Кажется такое усложнение может устранить преимущество этой структуры данных. Всё же это такая, весьма специфичная структура данных. Поэтому эджкейсы в ней норм, если их документировать.
Но вообще, хотелось бы понять, границы её применимости, где она лучше альтернатив работает. Может сделаете статью о конкретных её юзкейсах и сравнению с альтернативами (именно на этих юзкейсах). Тогда, кажется, будет меньше странных вопросов.
На самом деле, я не очень понял, почему Вы подаёте ниуникальность ключей, как какую-то особенность структуры. Ведь деревъя с неуникальными ключами точно также несложно делаются.
Если постараться, можно даже сделать хешмап с неуникальными ключами. С ним уже сложнее и нужно аккуратно быть. Но если не нужен порядок, то хешмап должен быть гораздо быстрее.
Здесь не очень очевидно. Речь же, разумеется, идёт не о том, чтобы анализировать руками — речь об автоматическом анализе. И там в одном случае нужно хешмап разворачивать, а в другом следить за указателем в данных. Но не суть — что то, что другое решаются.
Этот подход создаёт не больше трудностей (а то и меньше), чем виртуализация. По идее, хороший анализ девиртуализации спокойно может отменить все подобные приседания. Поэтому такой подход не масштабируется.
Если его пытаться масштабировать, то получится что-то в стиле vmprotect. То есть просто сделать виртуальную машину и транслировать код под эту вм. При этом, одна инструкция этой вм может делать весьма много действий. А чтобы масштабировать защиту, вм генерируется при каждой компиляции новая.
Да, но это же не имеет прямого отношения к шифрованию. Любой драйвер должен это учитывать, даже если он не занимается никаким шифрованием вовсе, разве не так?
Скорее, в каждом замке есть встроенный мастер-ключ, который его открывает (даже при смене основного ключа). Но да, что-то в этом роде
А почему шифрование должно влиять на производительность nvme, оно же просто делается а памяти ОС, в качестве предобработки?
Тут скорее дело в том, что сам драйвер шифрования могли криво написать, который в принципе плохо с nvme работает — даже с выключенным шифрованием.
Проблема не в ip. С достаточной прозрачностью доставки обновлений, делать таргетированные апдейты нельзя.
Впрочем, если брать условный дебиан, то, по идее, если скомпрометировать популярные зеркала то, по идее, можно попробовать отдать таргетированно другую информацию... Хотя достаточно сложные условия на атаку (Option, уловить момент обновления, уловить нужные зеркала и пр.).
В любом случае, на порядок сложнее, чем в браузере
Не уверен, что готов согласиться. Не помню точных подробностей (источник вроде вот этот документ), поэтому опишу по памяти. Для каждого раздела мастер ключ шифрования храниться в нескольких экземплярах. Некоторые из них зашифрованы паролем пользователя(что логично), однако другие зашифрованы ассиметричным образом. Для последних сделана приписка "you don't need these unless you are an apple employee".
Соответственно, напрашивается вывод, что владелец приватного ключа (то есть apple), может при желании расшифровать раздел без доступа к паролю пользователя. Что в целом логично, т.к. пользователи любят забывать пароли.
У apple есть техническая возможность расшифровать диски. Но, возможно, у них юридически это более удачно оформлено.
Апдейт с руткитом отправить не выйдет, т.к. не выйдет сделать таргетированный апдейт (он тогда прилетит всем...). Если уж таким заниматься, то нужен бэкдор, при том не в апдейте — а на постоянной основе.
Неточные инструменты тоже бывают полезными. Всякими фильтрами блума, или hyperloglog-ом вполне себе успешно пользуются. Ну и в целом, что ssd/had, что ram — штуки не шибко точные. Но ничего, пользуемся.
А, уже теперь...
До релиза раст детектировал такие паники и выдавал именно что ошибку. Перед реализовать это превратили в линт, который к тому же был выключен. Видимо некоторое время назад этот линт сделали deny by default.
Но линт, на то и линт, что он распознает эти паники эвристиками. Поэтому иногда не очень хорошо срабатывает (например)
Это Вы откуда-то из 2014 пришли. Сейчас это уже рантайм паника.
Вопрос не в том, чтобы убедиться что нет конкретной лазейки. Вопрос в том, что доказать отсутствие бэкдоров внешними методами — крайне проблематично.
Не знаю. Если Вы хотите, чтобы Вашим приложением пользовались в качестве "приватного мессенджера" — то открыть прийдётся. Если же Ваша ЦА — обычные пользователи, которым просто нужен мессенжер (удобный, красивый, etc), то можете не открывать.
Если что, открытие исходников не означает отсутствие заработка. Можете рассмотреть разные модели монетизации.
Вопрос именно в том, что открытые исходники есть необходимый пререквизит к приватному мессенжеру. Если мы о реальной приватности, а не о маркетинге, конечно
Я регулярно сталкиваюсь с виндовыми системами, которые разваливались от такого подхода (и становились неработоспособными).
Анализ сложности этой структуры весьма нетривиальный. Если Вы, конечно, хотите оценки с логарифмами получить, а не с
на каждую операцию.
Тогда разделите статью на две. Иначе в обсуждениях каша из мнений.
Есть механизмы стеганографии по встраиванию бэкдора в криптографию. Например, можно к каждому шифрованному офферу прилагать метаинформацию, зашифрованную публичным ключом злоумышленика. Или в самом p2p соединении оставлять шифрованный блок.
Дальше продать эту информацию провайдерам/точкам обмена трафиком и профит. Ну или мониторить офферы и собирать информацию.
Или в другую сторону: а сколько по времени нужно производить эксперимент по мониторингу? Что если приложение выходит на связь только раз в сутки, в глубокую ночь?;)
И напомню, что всю процедуру проверки необходимо повторять после каждого обновления. С нуля, т.к. неизвестно что поменялось.
Короче говоря, нет. Закрытые исходники — это крест на доверии/приватности.
А стоит ли? Кажется такое усложнение может устранить преимущество этой структуры данных. Всё же это такая, весьма специфичная структура данных. Поэтому эджкейсы в ней норм, если их документировать.
Но вообще, хотелось бы понять, границы её применимости, где она лучше альтернатив работает. Может сделаете статью о конкретных её юзкейсах и сравнению с альтернативами (именно на этих юзкейсах). Тогда, кажется, будет меньше странных вопросов.
Хранить деревья отрезков вместо сегментов. По идее должно быть достаточно быстро.
На самом деле, я не очень понял, почему Вы подаёте ниуникальность ключей, как какую-то особенность структуры. Ведь деревъя с неуникальными ключами точно также несложно делаются.
Если постараться, можно даже сделать хешмап с неуникальными ключами. С ним уже сложнее и нужно аккуратно быть. Но если не нужен порядок, то хешмап должен быть гораздо быстрее.