Про картинки с замазаными данными. Частично прятать нельзя, нужно всегда полностью черным всё перекрывать, с запасом. Сейчас, например, с лёгкостью можно прочитать VID (остальное тоже). Полностью не буду его тут печатать, но первая закрытая буква E, а вторая W, так? Остальные тоже легко читаются. В некоторых случаях может 1-2 символа придется подбирать (но не из всех возможных).
Дело в том, что уже не в процессах дело. Атака Meltdown позволяет добыть данные из ядра и из других процессов (с некоторыми мелкими оговорками). Без разницы где конкретно данные лежат, в отдельном процессе или в том же самом.
Полного рабочего кода там быть и не может по определению, у white hat исследователей не принято эксплоиты такой величины публиковать чтобы каждый дурак мог копировать и использовать.
Attacks using JavaScript. In addition to violating process isolation oundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by ounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.
Не нужно компрометировать популярный сайт, я прямо сейчас на своём сайте пишу яваскрипт (и даю на него ссылку) который из брауера будет таскать всё что может. У вас несколько вкладок открыто? Даже может быть несколько програм (одна из них — менеджер паролей?), так?
А на ссылку, которую я дал, вы нажали? :-)
Пароли и ключи шифрования в памяти найти относительно просто.
Пароль можно просто подбирать из найденного в памяти. У ключей энтропия выше чем у остальных данных обычно, если при этом мониторить трафик, то можно проверять гипотетические ключи.
С таким объяснением достаточно серьёзно проблема выглядит?
Почему угадать сторону монеты 25%?
Допустим монетка сбалансирована и вероятность что выпадет Орел (О) и Решка(Р) по 50%.
Тогда есть 4 исхода событий (прогноз — реальность): О-О, О-Р, Р-О и Р-Р. В двух исходах прогноз совпадает с выпавшей стороной (О-О и Р-Р), всего вариантов 4, выходит вероятность угадать какой стороной упадет монетка 2 / 4 = 0.5 т.е. 50%.
На практике значения M и по крайней мере или e, или d очень велики.
Уточню про d и e: когдя генерируют ключи RSA для шифрования, то специально берут маленькое e (потом вычисляют d, которое выходит большим). Смысл в том чтобы шифровать можно было быстро быстро, шифровать будут все чтобы отправить сообщение мне, а расшифровывать буду только я (вычисления становятся проще для большего числа людей), плюс еще и открытый ключ чуть короче выходит. Для электронной подписи всё ровно наоборот.
Могу ошибаться, но есть такое мнение, что в случае, если внезапно придумают успешную атаку на AES-128, возможно, в 2 раза больший ключ будет чуть сложнее взломать, а может и нет, а вот более медленная расшифровка AES 256 нам скорее на руку, т.к. замедляет перебор, но не настолько, чтобы это было визуально заметно.
С точки зрения теории, на AES успешная атака уже есть (biclique), но она всего на пару бит снижает защиту (и требует уйму ресурсов во всех вариантах: 128, 192 и 256 бит).
А вот если вдруг появится квантовый компьютер, тогда да, можно будет поделить длинну ключа на два. Размер хеша тоже можно будет пополам разделить (в смысле безопасности). Но в этом случае RSA вообще нужно будет выкинуть.
По поводу «256 больше 128»: согласен, да, но нет :) не в случае с AES. Дело в том что на AES-256 есть атака, которая снижает уровень безопасности с 256и до ~100 бит, а вот на AES-128 эквивалента этой атаки нет (точнее есть, но не на полные 10 раундов). Хотя зумечу, это всё равно на практике провернуть будет слишком сложно (сегодня). Проще действительно на слабый мастер пароль нацелить усилия.
В общем, идея с размерами ключа более или менее ясна, хотя раз 256>128, то можно взять SHA512 и RSA «более толстый». Я, собственно, только по тому и поинтересовался, что на мой взгляд размеры ключей друг другу не соответствуют.
То что есть возможность заменить алгоритмы и всё это продумано с самого начала и заложено в идею — это очень даже правильно.
Спасибо. Еще у меня такой вопрос: зачем вам AES-256, когда AES-128 хватило бы с головой?
Особенно, если учесть что у вас RSA-2048 (примерно 128 бит «криптостойкости») и SHA-256 (тоже 128 бит защиты т.к. парадокс дней рождения). Плюс на AES-256 больше атак чем на AES-128 (key schedule). Ну, и, AES-128 был бы бустрее, ибо 10 раундов вместо 14ти.
Выходит вам явно 128-битная версия больше подошла бы или у вас на этот счёт какие-то другие соображения?
По моему, у этого словосочетания нет хорошего аналога в русском. Есть разница между «confidential» и «sensitive» по отношению к информации. С первым словом вроде всё ясно: секрет и всё (типа ключ шифрования или пароль). Второе совсем уж конфиденциальным назвать нельзя, тут скорее что-то вроде «информация, которую не очень хочется публично и повсеместно всем подряд рассказывать». Думаю, хорошим примером будет полный список персональных данных включая имя, адреса, место работы, зарплата, банковский счёт, телефоны итд. Возможно другими хорошими примерами будут архитектура внутренней сети какой-нибудь комании или, скажем, хеш вашего пароля из базы данных.
А что скажете по поводу «sensitive data», которую многие переводят как «чувствительные данные»? По мне, лучше «уязыимые данные» или «конфиденциальная информация», хотя второе не всегда подходит.
В части номер 4.3 есть больше объяснений.
Не нужно компрометировать популярный сайт, я прямо сейчас на своём сайте пишу яваскрипт (и даю на него ссылку) который из брауера будет таскать всё что может. У вас несколько вкладок открыто? Даже может быть несколько програм (одна из них — менеджер паролей?), так?
А на ссылку, которую я дал, вы нажали? :-)
Пароль можно просто подбирать из найденного в памяти. У ключей энтропия выше чем у остальных данных обычно, если при этом мониторить трафик, то можно проверять гипотетические ключи.
С таким объяснением достаточно серьёзно проблема выглядит?
Допустим монетка сбалансирована и вероятность что выпадет Орел (О) и Решка(Р) по 50%.
Тогда есть 4 исхода событий (прогноз — реальность): О-О, О-Р, Р-О и Р-Р. В двух исходах прогноз совпадает с выпавшей стороной (О-О и Р-Р), всего вариантов 4, выходит вероятность угадать какой стороной упадет монетка 2 / 4 = 0.5 т.е. 50%.
Где в моих рассуждениях ошибка?
Уточню про d и e: когдя генерируют ключи RSA для шифрования, то специально берут маленькое e (потом вычисляют d, которое выходит большим). Смысл в том чтобы шифровать можно было быстро быстро, шифровать будут все чтобы отправить сообщение мне, а расшифровывать буду только я (вычисления становятся проще для большего числа людей), плюс еще и открытый ключ чуть короче выходит. Для электронной подписи всё ровно наоборот.
С точки зрения теории, на AES успешная атака уже есть (biclique), но она всего на пару бит снижает защиту (и требует уйму ресурсов во всех вариантах: 128, 192 и 256 бит).
А вот если вдруг появится квантовый компьютер, тогда да, можно будет поделить длинну ключа на два. Размер хеша тоже можно будет пополам разделить (в смысле безопасности). Но в этом случае RSA вообще нужно будет выкинуть.
По поводу «256 больше 128»: согласен, да, но нет :) не в случае с AES. Дело в том что на AES-256 есть атака, которая снижает уровень безопасности с 256и до ~100 бит, а вот на AES-128 эквивалента этой атаки нет (точнее есть, но не на полные 10 раундов). Хотя зумечу, это всё равно на практике провернуть будет слишком сложно (сегодня). Проще действительно на слабый мастер пароль нацелить усилия.
В общем, идея с размерами ключа более или менее ясна, хотя раз 256>128, то можно взять SHA512 и RSA «более толстый». Я, собственно, только по тому и поинтересовался, что на мой взгляд размеры ключей друг другу не соответствуют.
То что есть возможность заменить алгоритмы и всё это продумано с самого начала и заложено в идею — это очень даже правильно.
Особенно, если учесть что у вас RSA-2048 (примерно 128 бит «криптостойкости») и SHA-256 (тоже 128 бит защиты т.к. парадокс дней рождения). Плюс на AES-256 больше атак чем на AES-128 (key schedule). Ну, и, AES-128 был бы бустрее, ибо 10 раундов вместо 14ти.
Выходит вам явно 128-битная версия больше подошла бы или у вас на этот счёт какие-то другие соображения?