И нафига нужна эта ваша квантовая криптография

[vitus_wagner]

Когда помещение рядом с компьютером чувствительного микрофона позволяет стырить секретные ключи.
Причем чувствительность обычного смартфона - достаточна.

Comments

[amarao-san.livejournal.com]

Я её всё ещё не дочитал. До середины я вообще думал, что ахинея, но идея repeative cycle меня убедила. (Любой, кто слышал как скроллится экран на звуковухе с хреновой развязкой по питанию, поймёт).

А вот как они сумели принудить gnupg к выполнению repeative cycle, да ещё такой, чтобы оно повторяло операцию с ключом достаточно долго - не знаю. Но, ещё не дочитал.

[qkowlew.livejournal.com]

Один из красивых вариантов - ведём активную переписку емейлом с атакуемым персонажем, шифруя отсылаемые ему письма его публичным ключом.

[amarao-san.livejournal.com]

Я не понимаю, какого размера должны быть письма, чтобы оно достаточно долго пищало. Мелкие письма расшифровываются слишком быстро, а гигантские аттачи просто будут долго читаться/получаться (то есть crypto там будет мало, а вот IOwait много).

[qkowlew.livejournal.com]

Если честно, я прочитал всё внимательно.
И пока мне не доведётся увидеть такое в реальной работе, немного не верю.

Реальная работа - это свежесетапленная заранее не известная демонстраторам система без софта, со всеми патчами, браусер, вебмейл, GPG плагин. Свежесгененрированная пара ключей, по емейлу отослан собеседнику публичный.

[filonov.livejournal.com]

Письма должны быть - во-первых большие, во-вторых их должно быть очень много (там надо двадцать замеров атаки на каждый из бит). В третьих - никто не будет вести активную переписку с атакующими битовыми последовательностями :). В четвертых - а как атакующий узнает, в какой момент начали расшифровывать именно его письмо.
Ну в качестве fatality - а если расшифровывать будут сразу два письма? :)

[filonov.livejournal.com]

1) показано что генерируемый шум зависит от исполняемого кода. Но нам то нужен не код а данные.
Данные что 1+1 и 1+0 дают разный шум - отсутствуют, хотя это первое что стоит проверить.
Т.е. фактически все что слышно - изменения алгоритма, который от данных зависит косвенно. Но таки зависит.

2) частота дискретизации.
для гигагерцовых частот процессора представляется крайне сомнительным, чтобы изменение 1го бита фонило на частоте 35-38кГц сколь-нибудь существенное время. Из п. 1 прямо следует, что для получения результата необходимы многократные повторения на сгенерированных атакующим данных. Они там по 20 раз проводят атаку на каждый бит и берут среднее. Т.е. не невозможно, но абсолютно бессмысленно для любых практических применений.

3) Утверждается что параллельная загрузка скорее помогает атакующему понижая частоту шума.
Замеряли они вводя параллельный поток с ADD. Возникает банальный вопрос - если параллельно будет считаться два разных RSA с разными ключами - какой из ключей будет уязвим?

[amarao-san.livejournal.com]

Я бы даже уточнил, насчёт параллельной нагрузки. Если есть параллельный поток с ADD, отлично, всё хорошо. А если поток не с бесконечным ADD, а, например, с ютубовским роликом через флеш, в котором операции, хм, несколько более разнообразны, чем в зацикленном add?

[filonov.livejournal.com]

В любой современной системе и без ютубовского ролика крутится дофига всего.
И довольно много из этого всего использует шифрование. Браузер с потоком https, ssh/ssl, внутрисистемные шифрованные операции. Ну и сжатие - тоже будет давать своеобразные паттерны в звуке.