при действительно простом мы найдём(можно оценить вероятность от s) такое
Самое интересное - эти вероятности и, в целом, требуемые значения s - как раз и не приведено в статье... Без этого вообще непонятно, сколько этот алгоритм будет работать, и насколько он конкурентоспособен по сравнению с другими алгоритмами.
Окей, расскажите, пожалуйста, как зашифровать накопитель при условии, что компьютером с Windows пользуются несколько человек, каждый со своей учёткой, и нежелательно, чтобы все они знали пароль от зашифрованного накопителя? Поскольку утекший от одного пользователя пароль сразу даёт атакующему возможность загрузиться с внешнего накопителя, расшифровать диск и получить доступ к данным всех пользователей.
Не совсем понятна проблема - почему не выделить каждому пользователю по отдельному разделу ФС, который шифруется паролем этого пользователя? Тут единственная проблема не в шифровании самом по себе, а в атаках брутфорсом - если пароль недостаточно длинный/случайный, то N часов/дней может быть достаточно для его взлома; TPM тут может помочь как "замедлитель" атаки брутфорсом. Однако принципиально в шифровании данных per-user никакой проблемы нет и в отсутствии TPM.
UPD Не совсем понятно - это разработчики базы данных такой "подарок" положили, что xp_cmdshell можно включать переконфигурацией прямо из SQL-запроса? Или всё-таки по умолчанию это невозможно сделать, и подарок взломщикам был сделан админами, которые эту опцию специально разрешили?
Интересно, что - следствие описанного в статье развития языка? - похоже, носители славянских языков гораздо лучше справляются с "парсингом" шипящих в слышимой речи. Для многих немцев на слух практически нет разницы между "тш" и "ч"; пресловутая "Дойчланд" на самом деле половиной (или даже большинством?) носителей произносится как "Дойтшланд". И скольких преподавателей-носителей языка я ни спрашивал - а как надо, с "тш" или "ч"? - они не то что ответить, даже суть вопроса не могли понять...
Стоимость этого проекта составила 150 млн. долларов. Жалко, что всего один раз в пару лет находятся средства на такие проекты - ведь наверняка каждый полёт возвращает данные, значительно продвигающие науку вперёд... (Глянул для сравнения из интереса - бюджет одной только Формулы-1 в 2020 г. оценивали в 2,42 млрд. долларов; грубо говоря, один гоночный болид примерно эквивалентен по цене "Хаябусе".)
Это забавно, что вы упомянули про "ничего", потому что в вашей модели атак, как раз-таки, "ничего" будет идеальной системой защиты! Потому что если сервер не спрашивает ни одного символа пароля, то и кейлоггер не запишет ни одного символа - вот и идеальный результат в предложенной вами attack surface. По меньшей мере тут уже можно понять, насколько абсурден анализ, проводимый из таких предпосылок...
Речь не про частичные пароли, а про ваш вывод, что сценарий B более защищён, чем другой. Повторюсь, этот вывод является манипуляцией: на основе одной формулы, которая оценивает только один из аспектов безопасности, делается вывод об общем превосходстве этой схемы над другой. Однако это вывод так же неверен, как, например, говорить "давайте предположим, что атакующий не будет использовать атаки по словарю" и на основе этой предпосылки делать рекомендации о применении схем безопасности.
Неужели вы не видите противоречия между тем, что, как вы согласились, предложенный сценарий "B" приближает нас к варианту с односимвольным челленджем, и очевидной небезопасностью односимвольного челленджа? Что условную устойчивость к кейлоггингу мы покупаем ценой компроментации всей схемы, фактически укорачивая запрашиваемые пароли?
Так ведь без этого какие выводы можно делать о реальной устойчивости схемы? Упражнения на комбинаторику в статье проделаны хорошие, только вот к выводу "сценарий B имеет значительно более высокую стойкость к взлому" они никак не приводят. В лучшем случае это введение читателей в заблуждение, в худшем - кто-то пойдёт на поводу у статьи и эту, простите, ерунду в реальный продакшен выкатит...
Предложенная attack surface не очень понятная. Если мы рассматриваем только этот вид атак, то самой выгодной станет схема "спрашивать по одному символу пароля". В вашей модели attack surface (с затаившимся взломщиком) это даст самое медленное раскрытие информации, хотя в реальности, разумеется, это абсолютно небезопасная схема, потому что любому "не таящемуся" атакующему достаточно будет угадать один символ для успешного взлома. Ваша схема "B" - это просто один шаг в направлении этой схемы, но уже этот шаг понижает общую устойчивость к взлому.
Но все же, запросы вида «Введите символы 1,1,3» или, тем более, «Ждем позиций 7,7,7» будут выглядеть несколько странно.
Это не просто странно, а фактически уменьшает длину запроса (потому что для атакующего эти два запроса - то же самое, что "1,3" и "7", соответственно), повышая вероятность успешного брутфорса выше. Например, при запросе "7,7,7" атакующему, вообще не знающему ничего об искомом пароле, надо просто угадать один символ из алфавита - что, очевидно, гораздо менее безопасно обычной схемы с несколькими запрашиваемыми символами.
Видим, что хотя на первых нескольких попытках вероятность ответа чуть ниже у сценария A (так как в запросе не может быть повторов), но для всех остальных значений сценарий B имеет значительно более высокую стойкость к взлому.
Но ведь формулы, приведённые в статье перед этой фразой, говорят не о стойкости к взлому, а о - цитата - "вероятность того, что в очередном запросе будут позиции символов, которые ему уже известны". Что, как бы, и так понятно из неформальных рассуждений: если схема такова, как "B", что она иногда спрашивает у пользователя меньше символов, то и кейлоггер будет в среднем накапливать меньше данных, да и более короткий запрос имеет меньшие шансы пересечься с уже накопленным. Только вот как это коррелирует с общей безопасностью схемы? Мы же ухудшаем устойчивость одного запроса к взлому: во-первых, атакующему проще угадать ответ на один запрос из-за его возможно меньшей длины (см. начало комментария), а, во-вторых, ценность каждого утекшего символа растёт (пользуясь вашими примерами - для ответа на запрос "7,7,7" атакующему достаточно знать один-единственный утекший символ №7).
Смарт-карты вполне себе поддерживают многие "стандартные" алгоритмы, например, спецификация PIV-карт SP 800-78-4 предусматривает AES-128, AES-192, AES-256.
Нет никакой загадки в том, по какой причине она относит какой-либо сигнал к экзопланете. Учёным легко объяснить, какие именно особенности данных приводят ExoMiner к тому или иному выводу.
Вопрос к специалистам: это правда возможно в случае нейросетей? Или "художественное преувеличение"?
Немного странно, что текст до ката и две трети всей статьи - какие-то детали карьерного роста кого-то (простите, если это знаменитость). После такого заголовка хочется видеть хоть какие-то намёки по поводу того, что же такое интересное они там несколько лет пилят, а не простыню личной биографии с вкраплениями технической информации...
Про mmap я имел в виду, что если аллокатор не делает низкоуровневого управления памяти, а просто вызывает mmap, то в ответ от mmap он будет получать какие-то адреса в случайных местах в памяти. Тогда для реализации owns() аллокатору придётся держать какую-то вспомогательную структуру данных, в которой будут храниться все выделенные через него адреса. Что выглядит как ещё одна большая проблема в предложенной архитектуре...
Что такое x? Не вижу этой переменной больше нигде
Самое интересное - эти вероятности и, в целом, требуемые значения s - как раз и не приведено в статье... Без этого вообще непонятно, сколько этот алгоритм будет работать, и насколько он конкурентоспособен по сравнению с другими алгоритмами.
Согласен, что по тысяче зондов в год, даже при наличии бюджета, запускать прямо сейчас не вышло бы. С другой стороны, речь про человечество в целом - помимо Японии есть ещё несколько стран в мире, которые "потянули" бы такой проект. Ну, я понимаю, что они и "тянут" (https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BC%D0%B5%D0%B6%D0%BF%D0%BB%D0%B0%D0%BD%D0%B5%D1%82%D0%BD%D1%8B%D1%85_%D0%BA%D0%BE%D1%81%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85_%D0%B0%D0%BF%D0%BF%D0%B0%D1%80%D0%B0%D1%82%D0%BE%D0%B2), только не с самой впечатляющей частотой...
Я не проверял первоисточники, но в Википедии эта сумма указана как сумма для всего проекта, не только спутника.
Не совсем понятна проблема - почему не выделить каждому пользователю по отдельному разделу ФС, который шифруется паролем этого пользователя? Тут единственная проблема не в шифровании самом по себе, а в атаках брутфорсом - если пароль недостаточно длинный/случайный, то N часов/дней может быть достаточно для его взлома; TPM тут может помочь как "замедлитель" атаки брутфорсом. Однако принципиально в шифровании данных per-user никакой проблемы нет и в отсутствии TPM.
UPD Не совсем понятно - это разработчики базы данных такой "подарок" положили, что xp_cmdshell можно включать переконфигурацией прямо из SQL-запроса? Или всё-таки по умолчанию это невозможно сделать, и подарок взломщикам был сделан админами, которые эту опцию специально разрешили?
Интересно, что - следствие описанного в статье развития языка? - похоже, носители славянских языков гораздо лучше справляются с "парсингом" шипящих в слышимой речи. Для многих немцев на слух практически нет разницы между "тш" и "ч"; пресловутая "Дойчланд" на самом деле половиной (или даже большинством?) носителей произносится как "Дойтшланд". И скольких преподавателей-носителей языка я ни спрашивал - а как надо, с "тш" или "ч"? - они не то что ответить, даже суть вопроса не могли понять...
Стоимость этого проекта составила 150 млн. долларов. Жалко, что всего один раз в пару лет находятся средства на такие проекты - ведь наверняка каждый полёт возвращает данные, значительно продвигающие науку вперёд... (Глянул для сравнения из интереса - бюджет одной только Формулы-1 в 2020 г. оценивали в 2,42 млрд. долларов; грубо говоря, один гоночный болид примерно эквивалентен по цене "Хаябусе".)
Это забавно, что вы упомянули про "ничего", потому что в вашей модели атак, как раз-таки, "ничего" будет идеальной системой защиты! Потому что если сервер не спрашивает ни одного символа пароля, то и кейлоггер не запишет ни одного символа - вот и идеальный результат в предложенной вами attack surface. По меньшей мере тут уже можно понять, насколько абсурден анализ, проводимый из таких предпосылок...
Речь не про частичные пароли, а про ваш вывод, что сценарий B более защищён, чем другой. Повторюсь, этот вывод является манипуляцией: на основе одной формулы, которая оценивает только один из аспектов безопасности, делается вывод об общем превосходстве этой схемы над другой. Однако это вывод так же неверен, как, например, говорить "давайте предположим, что атакующий не будет использовать атаки по словарю" и на основе этой предпосылки делать рекомендации о применении схем безопасности.
Можно ли в двух словах объяснить, в чём отличие от PyPy (и, если оба будет jit, то зачем их два)?
Неужели вы не видите противоречия между тем, что, как вы согласились, предложенный сценарий "B" приближает нас к варианту с односимвольным челленджем, и очевидной небезопасностью односимвольного челленджа? Что условную устойчивость к кейлоггингу мы покупаем ценой компроментации всей схемы, фактически укорачивая запрашиваемые пароли?
Так ведь без этого какие выводы можно делать о реальной устойчивости схемы? Упражнения на комбинаторику в статье проделаны хорошие, только вот к выводу "сценарий B имеет значительно более высокую стойкость к взлому" они никак не приводят. В лучшем случае это введение читателей в заблуждение, в худшем - кто-то пойдёт на поводу у статьи и эту, простите, ерунду в реальный продакшен выкатит...
Предложенная attack surface не очень понятная. Если мы рассматриваем только этот вид атак, то самой выгодной станет схема "спрашивать по одному символу пароля". В вашей модели attack surface (с затаившимся взломщиком) это даст самое медленное раскрытие информации, хотя в реальности, разумеется, это абсолютно небезопасная схема, потому что любому "не таящемуся" атакующему достаточно будет угадать один символ для успешного взлома. Ваша схема "B" - это просто один шаг в направлении этой схемы, но уже этот шаг понижает общую устойчивость к взлому.
Странный какой-то анализ...
Это не просто странно, а фактически уменьшает длину запроса (потому что для атакующего эти два запроса - то же самое, что "1,3" и "7", соответственно), повышая вероятность успешного брутфорса выше. Например, при запросе "7,7,7" атакующему, вообще не знающему ничего об искомом пароле, надо просто угадать один символ из алфавита - что, очевидно, гораздо менее безопасно обычной схемы с несколькими запрашиваемыми символами.
Но ведь формулы, приведённые в статье перед этой фразой, говорят не о стойкости к взлому, а о - цитата - "вероятность того, что в очередном запросе будут позиции символов, которые ему уже известны". Что, как бы, и так понятно из неформальных рассуждений: если схема такова, как "B", что она иногда спрашивает у пользователя меньше символов, то и кейлоггер будет в среднем накапливать меньше данных, да и более короткий запрос имеет меньшие шансы пересечься с уже накопленным. Только вот как это коррелирует с общей безопасностью схемы? Мы же ухудшаем устойчивость одного запроса к взлому: во-первых, атакующему проще угадать ответ на один запрос из-за его возможно меньшей длины (см. начало комментария), а, во-вторых, ценность каждого утекшего символа растёт (пользуясь вашими примерами - для ответа на запрос "7,7,7" атакующему достаточно знать один-единственный утекший символ №7).
Смарт-карты вполне себе поддерживают многие "стандартные" алгоритмы, например, спецификация PIV-карт SP 800-78-4 предусматривает AES-128, AES-192, AES-256.
Вопрос к специалистам: это правда возможно в случае нейросетей? Или "художественное преувеличение"?
Паранойя паранойей, но эллиптические кривые гораздо быстрее же.
Немного странно, что текст до ката и две трети всей статьи - какие-то детали карьерного роста кого-то (простите, если это знаменитость). После такого заголовка хочется видеть хоть какие-то намёки по поводу того, что же такое интересное они там несколько лет пилят, а не простыню личной биографии с вкраплениями технической информации...
Idea виснет от неработающего гитхаба?
Про mmap я имел в виду, что если аллокатор не делает низкоуровневого управления памяти, а просто вызывает mmap, то в ответ от mmap он будет получать какие-то адреса в случайных местах в памяти. Тогда для реализации owns() аллокатору придётся держать какую-то вспомогательную структуру данных, в которой будут храниться все выделенные через него адреса. Что выглядит как ещё одна большая проблема в предложенной архитектуре...