[HN Gopher] Is your SSH key still safe?
       ___________________________________________________________________
        
       Is your SSH key still safe?
        
       Author : dz0ny
       Score  : 21 points
       Date   : 2022-04-15 12:52 UTC (10 hours ago)
        
 (HTM) web link (aremykeyssafe.com)
 (TXT) w3m dump (aremykeyssafe.com)
        
       | CodesInChaos wrote:
       | Ed25519 is defined over the 255 bit field GF(2^255-19) and thus
       | has fixed size keys, so having key size recommendations for it is
       | silly. (The underlying EdDSA can be generalized to other sizes).
       | 
       | 256-bit ECDSA is fine, it offers the same theoretical security
       | level as Ed25519. Its main problem is that historically
       | implementations were fragile (relying on high quality randomness
       | for signing) and not resistant to side-channel attacks.
        
         | free-malloc wrote:
         | > For the ED25519, the key size should be 256 or larger.
         | 
         | This made him seem like a non expert. ED25519 is 256 bits
         | always: https://ed25519.cr.yp.to/
        
       | walrus01 wrote:
       | i wonder what would happen if you made a site this that looked
       | similar and asked people to upload their private ssh key to
       | "check if it's safe". Sort of like the phishing sites that ask
       | you to type your whole credit card number to "see if it's been
       | compromised".
       | 
       | based on the number of people I've seen that totally don't
       | understand the concept between the public and private portions of
       | their key, I bet you'd collect a lot.
        
         | glmdev wrote:
         | I 100% assumed that's what this would be until I clicked on it.
         | I feel like a large portion of (especially beginner) SSH users
         | don't really understand asymmetric encryption enough to
         | understand the implications there.
        
       | exabrial wrote:
       | > For the ECDSA algorithm, it should be 521.
       | 
       | Not that I'm discouraging people to use stronger security, by
       | P-256 is perfectly safe. If you can wait an extra second or two
       | for some connect operations, use P-521 or ED25519.
       | 
       | Honestly, I wish PGP was widely accepted. My "persistent"
       | identity has a very long key, and I create "A" (auth) keys that
       | expire. GPG has an SSH agent it's quite beautiful. SSH keys by
       | themselves do all of this key management and rotation by hand and
       | I find it quite silly.
        
         | aborsy wrote:
         | What keys you use for your persistent identity?
        
         | sascha_sl wrote:
         | PGP is not widely accepted because keeping persistent keys is
         | not a skill the average person in IT, let alone generally has.
         | It is also very hard to fix errors.
         | 
         | Using subkeys without the certify key has always been a bit of
         | a hack. GPG doesn't even have a nice command to pull out the C
         | key from your keychain and save it somewhere else.
         | 
         | FIDO2 keys for SSH are much better for the average person.
        
           | upofadown wrote:
           | >Using subkeys without the certify key has always been a bit
           | of a hack.
           | 
           | I am not sure what is meant by this. Standalone subkeys are
           | impossible. I think this might be a reference to the case
           | where you store the private key for the certify key somewhere
           | safer than the rest. Which, BTW, IMO, is something very few
           | people need to do, although it seems to have become somewhat
           | of a fad.
        
         | nousermane wrote:
         | > P-256 [or] wait an extra second [...] use P-521 or ED25519
         | 
         | Huh? I was under impression that any of those 3 take only a few
         | _milliseconds_ to compute, unlike classic RSA /DSA:
         | $ for i in \       > "-t ecdsa -b 256" \       > "-t ecdsa -b
         | 521" \       > "-t ed25519"; do       >   echo -n "$i "       >
         | (time for j in {1..1000}; do       >     rm -f deleteme       >
         | ssh-keygen $i -N "" -f deleteme       >    done) 2>&1 | grep
         | user       > done       -t ecdsa -b 256 user 0m1.887s       -t
         | ecdsa -b 521 user 0m2.172s       -t ed25519      user 0m3.382s
        
           | exabrial wrote:
           | It's the connect operations I was referring to. For me,
           | depending on the system I'm connecting to, there can be 1s-2s
           | longer connection delay depending on a lot of factors like
           | network latency, bandwidth, and target system computational
           | power
        
           | upofadown wrote:
           | I don't think they were talking about key generation. Dunno
           | where they were getting the extra second from.
        
       | moasda wrote:
       | tl;dr - "you need to make sure your keys are using strong
       | encryption by not having old keys laying around."
        
       ___________________________________________________________________
       (page generated 2022-04-15 23:03 UTC)