4 ms·

key[31]=(key[31]&63)|64;key[0]&=248; is radically simpler and not remotely comparable to the requirements for RSA key generation. Moreover, RSA key generation

by nullc 5y ago

key[31]=(key[31]&63)|64;key[0]&=248; is radically simpler and not remotely comparable to the requirements for RSA key generation. Moreover, RSA key generation is massively slow-- enough to be irritating for users even on fast computers so there is a lot of incentive to 'optimize' key generation and introduce complexity that results in bugs. (do not use, I just implemented what the GP poster said, didn't check if it what he said was correct, but it sounds right)

duskwuff 5y ago
> Moreover, RSA key generation is massively slow-- Not only is it extremely slow, but it's also non-deterministically slow -- there's no constant-time way to randomly generate an RSA key, because searching for suitable primes is a "guess-and-check" process. ECC key generation, on the other hand, is so fast that it's perfectly feasible to use it as part of the session negotiation process (e.g. in ECDHE).
thaumasiotes 5y ago
> (key[31]&63)|64 You confused me here; this looks like you're clearing the highest bit and then setting the highest bit... in a 7-bit integer. Of course it makes more sense that you're clearing the two highest bits and then setting the second-highest bit of an 8-bit integer, which is indeed the same thing as clearing the highest bit and then setting the second-highest bit. But why have you written it to fiddle the second-highest bit twice? Why not just write `(key[31]&127)|64`? (And then of course, why not use the hexadecimal form of your bitfield constants so people can tell what's going on? No need to count bits that way.)
- nullc 5y ago
  just because 63 was a shorter constant to type than 127. Hex would have been longer due to the prefix. :P
  - emj 5y ago
    Thank you for that self analyzing! I got lost on that part, so will now stop writing ping 127.1 just to save four bytes. I've always felt that people learnt things by seeing that, but now I know I'm too lazy to bother learning myself.

by nullc 5y ago

duskwuff 5y ago

> Moreover, RSA key generation is massively slow-- Not only is it extremely slow, but it's also non-deterministically slow -- there's no constant-time way to randomly generate an RSA key, because searching for suitable primes is a "guess-and-check" process. ECC key generation, on the other hand, is so fast that it's perfectly feasible to use it as part of the session negotiation process (e.g. in ECDHE).

thaumasiotes 5y ago

> (key[31]&63)|64 You confused me here; this looks like you're clearing the highest bit and then setting the highest bit... in a 7-bit integer. Of course it makes more sense that you're clearing the two highest bits and then setting the second-highest bit of an 8-bit integer, which is indeed the same thing as clearing the highest bit and then setting the second-highest bit. But why have you written it to fiddle the second-highest bit twice? Why not just write `(key[31]&127)|64`? (And then of course, why not use the hexadecimal form of your bitfield constants so people can tell what's going on? No need to count bits that way.)

nullc 5y ago
just because 63 was a shorter constant to type than 127. Hex would have been longer due to the prefix. :P
- emj 5y ago
  Thank you for that self analyzing! I got lost on that part, so will now stop writing ping 127.1 just to save four bytes. I've always felt that people learnt things by seeing that, but now I know I'm too lazy to bother learning myself.