1) показано что генерируемый шум зависит от исполняемого кода. Но нам то нужен не код а данные. Данные что 1+1 и 1+0 дают разный шум - отсутствуют, хотя это первое что стоит проверить. Т.е. фактически все что слышно - изменения алгоритма, который от данных зависит косвенно. Но таки зависит.
2) частота дискретизации. для гигагерцовых частот процессора представляется крайне сомнительным, чтобы изменение 1го бита фонило на частоте 35-38кГц сколь-нибудь существенное время. Из п. 1 прямо следует, что для получения результата необходимы многократные повторения на сгенерированных атакующим данных. Они там по 20 раз проводят атаку на каждый бит и берут среднее. Т.е. не невозможно, но абсолютно бессмысленно для любых практических применений.
3) Утверждается что параллельная загрузка скорее помогает атакующему понижая частоту шума. Замеряли они вводя параллельный поток с ADD. Возникает банальный вопрос - если параллельно будет считаться два разных RSA с разными ключами - какой из ключей будет уязвим?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
branchandroot
no subject
Date: 2013-12-19 10:36 am (UTC)Данные что 1+1 и 1+0 дают разный шум - отсутствуют, хотя это первое что стоит проверить.
Т.е. фактически все что слышно - изменения алгоритма, который от данных зависит косвенно. Но таки зависит.
2) частота дискретизации.
для гигагерцовых частот процессора представляется крайне сомнительным, чтобы изменение 1го бита фонило на частоте 35-38кГц сколь-нибудь существенное время. Из п. 1 прямо следует, что для получения результата необходимы многократные повторения на сгенерированных атакующим данных. Они там по 20 раз проводят атаку на каждый бит и берут среднее. Т.е. не невозможно, но абсолютно бессмысленно для любых практических применений.
3) Утверждается что параллельная загрузка скорее помогает атакующему понижая частоту шума.
Замеряли они вводя параллельный поток с ADD. Возникает банальный вопрос - если параллельно будет считаться два разных RSA с разными ключами - какой из ключей будет уязвим?