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

[Alicja Kario <[e-mail]>]

(sending again with the CCs cleaned up)

On Thursday, 5 September 2024 20:02:56 CEST, Alicja Kario wrote:
> On Thursday, 5 September 2024 19:21:39 CEST, Phillip Hallam-Baker wrote:
>> Very interesting. RSA will be with us for a long time...
>> 
>> Have you considered key generation? Just adding a reference to 
>> FIPS 185-5 might be enough. I am currently trying to decide 
>> whether probabilistic or provable primes are the way to go. I 
>> have also noticed that keygen on my state of the art 2023 
>> machine is taking almost as long as it used to take in 1990. 
>> That is because we are using longer keys and we are doing a lot 
>> more checks - the auxiliary primes.
>
> RSA key generation is a very rare occurance, so it's easier to just
> do it offline, on a trusted system, than to work to make it side
> channel safe. So, no, I consider it out of scope.
>
>> On the draft itself, I am not sure about calling Montgomery 
>> ladders 'side channel free'. They are really not. Hardware does 
>> too much weirdness these days for anything to be side effect 
>> free unless it is hardware designed to be so.
>
> I'm suggesting Montgomery ladder not because it's inherently side-channel
> free—it's not, as the draft explicitly states—but because it's one of
> the easiest ones to make side-channel free.
>
> While special hardware may help, I haven't seen that it's actually
> necessary on general purpose systems: my team and I have verified multiple
> implementations of RSA decryption to be side-channel free to
> sub nanosecond resolution. Same for particular big-int arithmetic
> primitives. For CPU scheduler, having operations that take the same amount
> of time makes handling the CPU state much easier, so I don't think
> it's so far fatched of a result.
>
> Honestly, I suspect that a lot of the "weirdness" you refer to comes
> from badly designed test scenarios, not actual lack of determinism
> in the hardware.
>
> And while yes, we can have a situation where multiplying zeros over and over
> will take less energy than multiplying random values over and over, and
> that can bleed into the CPU frequency, and thus be visible in the
> timing side channel, it's not something I have observed for the typical
> RSA key sizes, let alone something that's a valid attack vector for RSA.
>
>> On Tue, Sep 3, 2024 at 2:27 PM Alicja Kario <[e-mail]> wrote:
>> Hello,
>> 
>> In the main body of the draft there were just few minor changes:
>> few typos fixed.
>> 
>> The main change in revision 01 is the addition of actual test vectors ...
>

-- 
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