Bug 1641795 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(Hidden by Administrator)
Dear Thyla, thank you for the prompt response.

> To confirm, the crux of the attack is to find, using one of the possible timing side channels, an attacker-constructed handshake that results in a PMS with a leading zero byte, and then solving for the HNP produces g^{ab}, the targeted PMS. Is this right?

Correct. We note the attacker will have to collect many handshakes (~100 handshakes) that result in a PMS with a leading zero byte, and then feed those as input to the HNP.

> What do you mean by 'modest' here?

We used 64 cores.

> Do you have estimates on how much computational power would be required for the single-byte-leakage case to succeed?

Unfortunately no. We used the above 64 cores for many hours, trying several settings for the HNP solver, but it seems we were not even close for 1024-bit modoli. However, 768-bit modulo with a single byte leakage is feasible with our computational power. For 1024 bit moduli, we also could not provide any estimates by extrapolating from cases we could solve.

> Also, to use side channel 1, the hash function block border, it seems you need to be using a dangerous modulus size, i.e., non-standard, correct?

Correct.

> And in the DHE case, ephemerals have to be reused.

Correct.

>  The disclosure to potential USENIX reviewers, however, is set to happen within a much tighter time frame. Typically, I imagine that reviewers will respect any disclosure boundaries but we will also discuss this further within the team.

We imagine the concern is that reviewers might break the embargo, but we did not experience any problems with this in past projects. Please do let us know if this is a concern for you.

thank you again, best wishes,

Back to Bug 1641795 Comment 2