From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30404 invoked from network); 27 Nov 2023 00:36:39 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 27 Nov 2023 00:36:39 -0000 Received: from dpmailmta01.doteasy.com ([65.61.218.3]) by 9front; Sun Nov 26 19:33:47 -0500 2023 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=192.168.101.81; Received: from dpmailrp01.doteasy.com (unverified [192.168.101.81]) by dpmailmta01.doteasy.com (DEO) with ESMTP id 119527012-1394429 for <9front@9front.org>; Sun, 26 Nov 2023 16:33:40 -0800 Return-Path: Received: from dpmail01.doteasy.com (dpmail01.doteasy.com [192.168.101.1]) by dpmailrp01.doteasy.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTP id 3AR0XdTp021695 for <9front@9front.org>; Sun, 26 Nov 2023 16:33:40 -0800 X-SmarterMail-Authenticated-As: fde101@fjrhome.net Received: from [192.168.1.95] (pool-173-67-134-57.hrbgpa.fios.verizon.net [173.67.134.57]) by dpmail01.doteasy.com with SMTP (version=Tls12 cipher=Aes256 bits=256); Sun, 26 Nov 2023 16:33:19 -0800 Message-ID: <93ea7c66-2a72-4c60-9069-10f5986ced31@fjrhome.net> Date: Sun, 26 Nov 2023 19:33:12 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: <7D815659CDA544149A6CA4CB32684F2C@felloff.net> Content-Language: en-US From: "Frank D. Engel, Jr." In-Reply-To: <7D815659CDA544149A6CA4CB32684F2C@felloff.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Exim-Id: 93ea7c66-2a72-4c60-9069-10f5986ced31 X-Bayes-Prob: 0.0001 (Score 0, tokens from: base:default, @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.1 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01bfcxDTM - a6acf6d9551d - 20231126 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.81 X-Originating-IP: 192.168.101.81 List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: open secure service-based content-driven solution Subject: Re: [9front] auth/rsagen: bump bits to 4096 Reply-To: 9front@9front.org Precedence: bulk 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 >