[CFRG] Re: I-D Action: draft-irtf-cfrg-rsa-guidance-01.txt

[Mike Simpson <[e-mail]>]

Tbf there’s been loads of problems with having sufficient entropy to ensure randomness across many systems over the years and we seem doomed to repeat the same subtle logical bugs or straight out stupidity roughly every 15-20 years or so   

Outside of a lab, unless you’re running OpenBSD, givens are sometimes assumptions. 

Mike

> On 6 Sep 2024, at 17:06, Alicja Kario <[e-mail]> wrote:
> 
> On Friday, 6 September 2024 16:14:27 CEST, Riad S. Wahby wrote:
>> Hello Alicja,
>> 
>> Thanks for your message. I completely understand your position, so I guess
>> at this point I'm just advocating for the devil. But here goes, in reverse
>> order:
>> 
>> Alicja Kario <[e-mail]> wrote:
>>> Also, RFC 8017 says nothing about how to generate the RSA parameters.
>>> So, I consider key generation out of scope.
>>> See https://github.com/tomato42/marvin-ietf/pull/new/outside-scope
>>> for the proposed text.
>> 
>> This text is strictly true but also pretty unhelpful to the reader.
>> 
>> Reader thinks: "But I need to generate keys... so what do I do now?"
>> 
>> It seems like at the very least it makes sense to recommend generating keys
>> on a system that is safely hidden from prying eyes. And perhaps in this
>> context that's enough---even if it still seems like a missed opportunity
>> to help the reader by at least waving in the directin of countermeasures!
>> 
>>> The protections I talk in the Draft are for remote timing attacks,
>>> potentially conducted even over the Internet.
>>> How do you perform a remote network based attack against RSA key generation?
>> 
>> This question is hard to answer in part because answering "how" requires
>> knowing details of the system being attacked. I don't have those details.
>> 
>> But if you're asking, does there exist a system in which RSA key generation
>> can be attacked remotely via timing, my guess is very much yes: at this
>> point it seems prudent just to assume that remote timing attacks are always
>> practical in the absence of countermeasures. That's an over-approximation,
>> but recent history suggests it's not all that far off.
> 
> And I'm going to say that the answer is "no".
> 
> Because simple timing attacks require you to measure the same operation
> on the same secret values. If you have a situation where the attacker can
> force you to generate private keys with the same RNG seed values you
> have much bigger issues than side channel attacks.
> 
> So, just like Raccoon attack is impossible against server that uses ephemeral
> key shares, remote timing attacks against RSA key gen that uses actual
> entropy is not possible.
> 
> If you have a system that simply transmits in EM spectrum values
> of the registers before operating on them, then there's literally nothing
> we can do to protect against an attacker that can read the EM spectrum.
> But that's not the typical system and that's not the typical attacker.
> This is not a guide for designing TEMPEST hardened solutions.
> 
> So, please, let's focus on realistic scenarios, and not go into the weeds:
> don't let the perfect be the enemy of the good.
> 
>> Or, putting on my Captain Obvious hat: "we've taken steps to prevent X"
>> is always preferred to "we can't imagine how an attacker will do X".
>> 
>> I'll end my devil's advocacy here. And: thank you for doing the hard work
>> of writing down these valuable recommendations---please don't mistake
>> my free-floating anxiety for a failure to appreciate your efforts!
> 
> OK, I'll take it as the PR https://github.com/tomato42/marvin-ietf/pull/3
> being good enough.
> --
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
> 
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]