[9front] auth/rsagen: bump bits to 4096

[9front] auth/rsagen: bump bits to 4096

[Aaron Bieber]

Hola!

No argument from me that RSA should go the way of the dodo.. but until 
that day
we should probably default to 4096:

diff 04d6a2acecfe4fe44947da8b676f63bcd0f3c0fe uncommitted
--- a/sys/man/8/rsa
+++ b/sys/man/8/rsa
@@ -150,7 +150,7 @@
  .B n
  has exactly
  .I nbits
-(default 2048)
+(default 4096)
  significant bits.
  If
  .I tag
--- a/sys/src/cmd/auth/rsagen.c
+++ b/sys/src/cmd/auth/rsagen.c
@@ -18,7 +18,7 @@
      char *tag;
      RSApriv *key;

-    bits = 2048;
+    bits = 4096;
      tag = nil;
      key = nil;
      fmtinstall('B', mpfmt);

Re: [9front] auth/rsagen: bump bits to 4096

[cinap_lenrek]

whats your justification?

--
cinap

Re: [9front] auth/rsagen: bump bits to 4096

[Aaron Bieber]

On 11/26/23 05:48, cinap_lenrek@felloff.net wrote:
> whats your justification?

OpenSSH has defaulted to 3072 since 2019[1]. OpenSSH has also moved away 
from RSA[2].

My reasoning is basically since we don't have alternative key types 
(ed25519, ecdsa) for
general usage / ssh, bump the default to the highest available.

[1] 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-keygen.c?rev=1.328&content-type=text/x-cvsweb-markup
[2] 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-keygen.c?rev=1.273&content-type=text/x-cvsweb-markup
>
> --
> cinap

Re: [9front] auth/rsagen: bump bits to 4096

[ori]

Quoth Aaron Bieber <aaron@bolddaemon.com>:
> My reasoning is basically since we don't have alternative key types 
> (ed25519, ecdsa) for
> general usage / ssh, bump the default to the highest available.

why not DJB's post-quantum RSA proposal? I believe
that the key size used there was 8796093022208 bits.

Changing it isn't wrong, but there's no "highest
available" size for RSA. Why 4096 specifically?

Re: [9front] auth/rsagen: bump bits to 4096

[Aaron Bieber]

On 11/26/23 09:50, ori@eigenstate.org wrote:
> Quoth Aaron Bieber <aaron@bolddaemon.com>:
>> My reasoning is basically since we don't have alternative key types
>> (ed25519, ecdsa) for
>> general usage / ssh, bump the default to the highest available.
> why not DJB's post-quantum RSA proposal? I believe
> that the key size used there was 8796093022208 bits.
>
> Changing it isn't wrong, but there's no "highest
> available" size for RSA. Why 4096 specifically?
>
Ya, bad wording on my side. 4096 is the "max" supported by other tools,
gpg for example. So staying under that bar would allow for key-portability.
I am not married to it though.

Re: [9front] auth/rsagen: bump bits to 4096

[cinap_lenrek]

> My reasoning is basically since we don't have alternative key types 
> (ed25519, ecdsa) for general usage / ssh, bump the default to the
> highest available.

and if we had elliptic curve kex in ssh then you would keep the
default alone? what kind of logic is that?

rsa is also not just used for ssh, there might be implementations
out there that wont support rsa keys bigger than 2048 bits...

have you considered the impact at all?

whats the connecition establishment time with 2048 vs 4096 bit
rsa keys?

please do the homework.

--
cinap

Re: [9front] auth/rsagen: bump bits to 4096

[Aaron Bieber]

On 11/26/23 10:06, cinap_lenrek@felloff.net wrote:
>> My reasoning is basically since we don't have alternative key types
>> (ed25519, ecdsa) for general usage / ssh, bump the default to the
>> highest available.
> and if we had elliptic curve kex in ssh then you would keep the
> default alone? what kind of logic is that?

It's some logic you just made up :P - I never said I wouldn't propose 
changing
it if we had EC kex. I probably would have not picked 4096 though.
>
> rsa is also not just used for ssh, there might be implementations
> out there that wont support rsa keys bigger than 2048 bits...
>
> have you considered the impact at all?

I have, and my thoughts are if those things need smaller key sizes, they can
generate them.

> whats the connecition establishment time with 2048 vs 4096 bit
> rsa keys?
>
> please do the homework.

I haven't hit any issues - and I am on some pretty shitty internet. I 
haven't tested
extensively though. That said, IMO if people need speed they can still 
generate
smaller keys...

> --
> cinap

Re: [9front] auth/rsagen: bump bits to 4096

[cinap_lenrek]

> It's some logic you just made up :P - I never said I wouldn't propose 
> changing it if we had EC kex. I probably would have not picked 4096 though.

my point was that i do not see the connection between them.
what has the availability of ec todo with the rsa key size?
the only place where i see a connection is if you would want to "nudge"
users into not using rsa and for that you sabotage it beyond
any reason. but this would be pretty nasty thing todo no?

> I haven't hit any issues - and I am on some pretty shitty internet. I 
> haven't tested extensively though. That said, IMO if people need speed
> they can still  generate smaller keys...

common, just quantify it. whats the actual timing differences?
like make a test program i can run on my raspberry pi...
do SOMETHING usefull that helps quantifying the impact.

--
cinap

Re: [9front] auth/rsagen: bump bits to 4096

[Frank D. Engel, Jr.]

For SSH, key pairs often have a very long life span - far longer than 
they probably should.

In am aware of at least one place where DSA keys were still being used 
quite recently simply because they keep working and no one noticed or 
bothered to switch them out.

Presumably 2048-bit RSA is good until 2030 - but that is less than 7 
years away and keys created today may still be in use long past that time.

2048-bit keys are probably fine for certificates which expire before 
that time, but with ssh key pairs there is no such life span preventing 
them from outliving their safety margin.  Making keys as strong as 
possible now is, in my opinion, a better plan.

I always generate RSA keys as 4096-bit when I need to do so.


On 11/26/23 14:43, cinap_lenrek@felloff.net wrote:
>> It's some logic you just made up :P - I never said I wouldn't propose
>> changing it if we had EC kex. I probably would have not picked 4096 though.
> my point was that i do not see the connection between them.
> what has the availability of ec todo with the rsa key size?
> the only place where i see a connection is if you would want to "nudge"
> users into not using rsa and for that you sabotage it beyond
> any reason. but this would be pretty nasty thing todo no?
>
>> I haven't hit any issues - and I am on some pretty shitty internet. I
>> haven't tested extensively though. That said, IMO if people need speed
>> they can still  generate smaller keys...
> common, just quantify it. whats the actual timing differences?
> like make a test program i can run on my raspberry pi...
> do SOMETHING usefull that helps quantifying the impact.
>
> --
> cinap
>

Re: [9front] auth/rsagen: bump bits to 4096

[ori]

Quoth Frank D. Engel, Jr. <fde101@fjrhome.net>:
> 
> Presumably 2048-bit RSA is good until 2030 - but that is less than 7 
> years away and keys created today may still be in use long past that time.

This is getting closer to a useful description of why,
but can you explain *how* you concluded that these keys
are good until 2030?

Re: [9front] auth/rsagen: bump bits to 4096

[Frank D. Engel, Jr.]

This is the recommendation from NIST:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

A 2048-bit RSA key has a "security strength" of 112 bits (page 54).

NIST considers encryption with a security strength of 112 bits to be 
acceptable protection through 2030 but not beyond that (page 59).


See also: 
https://www.gradenegger.eu/en/which-key-sizes-should-be-used-for-certification-bodies-and-certificates/

That document indicates that a German government security organization 
considers less than 3000 bits with RSA to be unacceptable even now.


Of course, RSA is known to be vulnerable to an algorithm which could be 
implemented on a sufficiently large quantum computer; while such a 
computer is currently believed to be over a decade away, there have been 
known cases of full encrypted exchanges being captured and stored for 
longer periods of time than that to be decrypted after the technology 
improves to be able to crack the data.  Depending on the sensitivity of 
the information, this could be a factor for some.


There are groups making various efforts to develop new algorithms 
designed to be safe against quantum computers:

https://en.wikipedia.org/wiki/Post-quantum_cryptography



On 11/26/23 19:42, ori@eigenstate.org wrote:
> Quoth Frank D. Engel, Jr. <fde101@fjrhome.net>:
>> Presumably 2048-bit RSA is good until 2030 - but that is less than 7
>> years away and keys created today may still be in use long past that time.
> This is getting closer to a useful description of why,
> but can you explain *how* you concluded that these keys
> are good until 2030?
>
>
>

Re: [9front] auth/rsagen: bump bits to 4096

[hiro]

this doesnt sound very beleivable. or has somebody succeeded to
timetravel from 2030 and prove that there are usable quantum
computers?

i suggest not letting the quantumscarecrows onto this ml

On 11/27/23, Frank D. Engel, Jr. <fde101@fjrhome.net> wrote:
> This is the recommendation from NIST:
>
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
>
> A 2048-bit RSA key has a "security strength" of 112 bits (page 54).
>
> NIST considers encryption with a security strength of 112 bits to be
> acceptable protection through 2030 but not beyond that (page 59).
>
>
> See also:
> https://www.gradenegger.eu/en/which-key-sizes-should-be-used-for-certification-bodies-and-certificates/
>
> That document indicates that a German government security organization
> considers less than 3000 bits with RSA to be unacceptable even now.
>
>
> Of course, RSA is known to be vulnerable to an algorithm which could be
> implemented on a sufficiently large quantum computer; while such a
> computer is currently believed to be over a decade away, there have been
> known cases of full encrypted exchanges being captured and stored for
> longer periods of time than that to be decrypted after the technology
> improves to be able to crack the data.  Depending on the sensitivity of
> the information, this could be a factor for some.
>
>
> There are groups making various efforts to develop new algorithms
> designed to be safe against quantum computers:
>
> https://en.wikipedia.org/wiki/Post-quantum_cryptography
>
>
>
> On 11/26/23 19:42, ori@eigenstate.org wrote:
>> Quoth Frank D. Engel, Jr. <fde101@fjrhome.net>:
>>> Presumably 2048-bit RSA is good until 2030 - but that is less than 7
>>> years away and keys created today may still be in use long past that
>>> time.
>> This is getting closer to a useful description of why,
>> but can you explain *how* you concluded that these keys
>> are good until 2030?
>>
>>
>>
>
>

Re: [9front] auth/rsagen: bump bits to 4096

[Frank D. Engel, Jr.]

Two different things:

2030 is the year that NIST is estimating that *conventional* computers 
will approach being powerful enough to make a 2048-bit RSA key 
sufficiently insecure.

Quantum computers are expected to be further out but are expected to 
break even 4096-bit RSA much more quickly than conventional computers 
would so teams are working to replace RSA completely with new algorithms 
- that is on a different (and less well-understood) timetable.


On 11/27/23 04:50, hiro wrote:
> this doesnt sound very beleivable. or has somebody succeeded to
> timetravel from 2030 and prove that there are usable quantum
> computers?
>
> i suggest not letting the quantumscarecrows onto this ml
>
> On 11/27/23, Frank D. Engel, Jr. <fde101@fjrhome.net> wrote:
>> This is the recommendation from NIST:
>>
>> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
>>
>> A 2048-bit RSA key has a "security strength" of 112 bits (page 54).
>>
>> NIST considers encryption with a security strength of 112 bits to be
>> acceptable protection through 2030 but not beyond that (page 59).
>>
>>
>> See also:
>> https://www.gradenegger.eu/en/which-key-sizes-should-be-used-for-certification-bodies-and-certificates/
>>
>> That document indicates that a German government security organization
>> considers less than 3000 bits with RSA to be unacceptable even now.
>>
>>
>> Of course, RSA is known to be vulnerable to an algorithm which could be
>> implemented on a sufficiently large quantum computer; while such a
>> computer is currently believed to be over a decade away, there have been
>> known cases of full encrypted exchanges being captured and stored for
>> longer periods of time than that to be decrypted after the technology
>> improves to be able to crack the data.  Depending on the sensitivity of
>> the information, this could be a factor for some.
>>
>>
>> There are groups making various efforts to develop new algorithms
>> designed to be safe against quantum computers:
>>
>> https://en.wikipedia.org/wiki/Post-quantum_cryptography
>>
>>
>>
>> On 11/26/23 19:42, ori@eigenstate.org wrote:
>>> Quoth Frank D. Engel, Jr. <fde101@fjrhome.net>:
>>>> Presumably 2048-bit RSA is good until 2030 - but that is less than 7
>>>> years away and keys created today may still be in use long past that
>>>> time.
>>> This is getting closer to a useful description of why,
>>> but can you explain *how* you concluded that these keys
>>> are good until 2030?
>>>
>>>
>>>
>>