Hacker News Reader

Comment by developer2 | Hacker News Reader

Seriously, the default options to ssh-keygen should be all anybody needs. If you need to pass arguments to increase the security of the generated key, then the software has completely failed its purpose. Passing arguments should only be for falling back on less secure options, if there is some limiting factor for a particular deployment.

There is absolutely no reason to pass arguments to ssh-keygen. If it is actually deemed necessary to do so, then that package's installation is inexcusably broken.

View on HN

Not all systems that you might want to use your keys on support Ed25519, and this was especially true when it was first introduced to OpenSSH. Similarly not everything can handle the new key format. (Interestingly, there's another way to increase the resistance of SSH private keys to password brute-forcing that uses PBKDF2 and is more widely supported, but there's no way to create keys that use it using OpenSSH itself.)

Are you referring to something like this? http://blog.patshead.com/2013/09/generating-new-more-secure-...

> Passing arguments should only be for falling back on less secure options

This is the case with the secure-delete package for srm and sfill. Each argument changes the writes to make them less secure.

By default, ssh-keygen leaks info about your computer (``user@host''). Passing -C "" takes care of this.

I just throw a script in my ~/bin folder called `keygen`:

  exec ssh-keygen -t rsa -b 4096 -C "" "$@"

Why not just use an alias?

    alias keygen="ssh-keygen -t rsa -b 4096 -C ''"

Aliases are per shell process. You need to reload your .bashrc (or whatever file you define aliases in) in every shell. Shell scripts are instantly available in all shell instances. Also, shell scripts can be invoked by shell scripts, which aliases can't.

I agree, but for something as simple as that I’d prefer a script to use `ssh-keygen` instead of relying on the presence of a one-line script in the PATH.

If you're concerned about hostname leakage in your pubkeys, you're almost certainly doing something wrong.

If you want SSH access to Github or Gitlab, you'll need to paste your pubkey there. Leaking your user@host can be a concern if you're trying to maintain anonymity, e.g. Gwern, particularly if your username is your real name. You can strip out the user@host part from the paste, but it's safer to just get rid of it. It's easy to accidentally paste the whole thing into an .ssh/authorized_keys file, for example.

Admittedly this isn't an issue for most people.

If you're trying to maintain anonymity, why is your username your real name?

Even if it's not, your default hostname when using a MacBook Pro is typically "<username>s-MacBook-Pro.local" which reveals you're using a MacBook Pro. That info leak probably doesn't matter, but generally you want to reveal as little information as possible.

As one example, a hostname leak might hypothetically be useful for a spearfishing+XSS attack.

What kind of person cares enough about anonymity to change the comment in their ssh key, but not change the default hostname of their Mac? That person is very inconsistent.

Why does ssh-keygen include unnecessary information by default?

Because it helps usability when the user is editing ~/.ssh/authorized_keys - if the default is not changed, the key comment has some context, so finding the right key is easier.

I strip comments from my SSH keys too for the same reason you do. But most people don't seem to care and there is a reason for the default.

Hardly unnecessary. Very useful to see which key is what when you have multiple.

Your right. I just checked mine and it was:

esau@europa.hsd1.fl.comcast.net

Not a big deal but it does reveal my ISP and state.

Comment section is set to what it is because this is easier way to tell where the public key comes from. It vastly simplifies key management, which is much more important than the tiny bits of anonymity you get from not setting the comment.

Anonymity is a different issue from security. You might get a little extra of that by taking user info from keys, but IMO for anonymity you should ensure your user info does not link to the real person.

GitHub does not display the comment of the SSH key to the public, check yourself:

https://github.com/<username>.keys

You're writing as if a person can only ever have one pubkey, you can create a new pair just for github.

It's worth noting both GitHub and GitLab strip the comment off the keys.

https://github.com/Lattyware.keys - GitHub leave it blank:

  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGAx5F7iJTDwbPrdhrTtVdQRtozcRDvGNuU7BB+4+mHi
  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL6WfINFFvzT+Z+l5sYq9zJoyXPLL27v9vvE1+p1XOiW

https://gitlab.com/latty.keys - GitLab add a generated comment:

  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL6WfINFFvzT+Z+l5sYq9zJoyXPLL27v9vvE1+p1XOiW Gareth Latty (gitlab.com)
  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGAx5F7iJTDwbPrdhrTtVdQRtozcRDvGNuU7BB+4+mHi Gareth Latty (gitlab.com)

In my case, I'd actually quite like the comments to be left in, one of those is my personal key, one is for work. Differentiating is useful depending on why I have access.

Certainly, but your user@host will be leaked to the staff of Github / Gitlab and to anyone that compromises your account. The unfortunate thing about anonymity is that a small mistake can be costly. It depends what your threat model is, though.

How so? Why should I give out my username and host with the key? In many applications I see no need for them.

No, this is a completely unnecessary piece of information that ssh is unnecessarily jamming into the pubkey. What possible use does including the hostname of the generating machine serve for public key authentication?

Today it's my hostname. Tomorrow ssh-keygen (with default arguments) could start including more sensitive information, like the IPv6 address of my machine that's open to the internet and its exact OS version, and leave me open to a lot of attacks. Hence, I'm not going to trust the default arguments for it.

First, this field is important. It's not used for authentication in any way, as it's just an optional comment, ignored by sshd otherwise. It's not an information for sshd, though: it's information for human user. Without this comment you don't have an easy way to tell where the keys come from.

Second, if you don't trust ssh-keygen, why the heck do you use it in the first place?

I didn't say I don't trust it, just that I don't trust that it won't leak private info when using the default arguments.

Why it would suddenly leak such information? User+host is put in the comment field for dozen years already, if not longer (and has quite good explaination why it is there). Where does this distrust of yours come from? It's completely opaque to me.

Well. OP says ->Generate your new sexy Ed25519 key

I too, say, No f'ing thanks https://en.wikipedia.org/wiki/Curve25519 In cryptography, Curve25519 is an elliptic curve offering 128 bits of security - The curve is birationally equivalent to Ed25519, a Twisted Edwards curve.

Ecrypt II - the EU project into encryption security says: https://www.keylength.com/en/3/

That gives you

Very short-term protection against small organizations Should not be used for confidentiality in new systems

and is equivelent to an 816bit RSA key

So how is this new key "Sexy" in any way.

First of all the Ecrypt project is is really outdated. Second you're reading the table wrong. Curve25519 gives you 128 bit of symmetric security, but the curve is 255 bit long. So from your table this compares to 3248 RSA. Third I'm no fan of such key number tables, it's a bit arbitrary and doesn't really reflect the complexities of modern cryptography.

You are misunderstanding. Curve25519 offers 128 bits of symmetric security, or the equivalent of a 256 bit elliptic curve key.

even if that is true. its still not enough to protect anything of value.

That's not what your own source says about 128-bit symmetric keys:

> Long-term protection

> Generic application-independent recommendation, protection from 2016 to 2040

total nonsense.

25519 is an asymetric key using eliptic curves

As both rockdoe and hannob have mentioned, ed25519 provides the same attack resistance as a 128-bit symmetric cipher. This is even mentioned in the original DJB ed25519 paper:

> High security level. This system has a 2^128 security target; breaking it has similar difficulty to breaking NIST P-256, RSA with ≈ 3000-bit keys, strong 128-bit block ciphers, etc. (The same techniques would also produce speed improvements at other security levels.) The best attacks known actually cost more than 2^140 bit operations on average, and degrade quadratically in success probability as the number of bit operations drops.

->similar difficulty to breaking NIST P-256

which takes our comp sci lab 35 seconds on a cluster of 8 machines.

so still no.

If that's possible, I'm sure you'll have no difficulty finding a public source to cite that states the same.

All the public sources I've found say it is secure.

Except for the ones recommending 512bit EC's

Perhaps you can find the parameters for a 512bit,non NIST EC and we can both be happy?

Otherwise I'll stick with 8000 and 15424 RSA thnx.

Absolutely incorrect. Anything above 90-100 bits of effective (symmetric) strength is currently more than enough, even against nation state actors.

112 bit effective strength has been the required MINIMUM for FIPS/NIST since 2014. ->and that is just to protect you from NON nation state actors.

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublic...

Plus, we KNOW they were routinely breaking 64bit effective strength since the 90s, 30 years on we need a lot lot more than twice the strength, even against half decent hackers - but changing the backbone is considered "too expensive".

So that isn't ME saying the US doesn't have anything valuable enough to protect. Its the US standards agencies.

128 bits isn't twice as strong as 64 bits. 65 bits is twice as strong as 64 bits. 2^64 ~= 10^19 - or 10 million million million times stronger.

technically its around ln(n)ln(ln(n)) stronger "best case"

thats a lot closer to 2 than 10 million million million

whoever taught you integer factorisation and the dlp are order c^n was either lying to you or had been lied to.

If it really was equivalent to 816bit rsa, messages encrypted with it would be cracked within hours, and nobody would use ecc... I'd like to see proof that a 256bit Curve25519 is really that weak.

Reply on news.ycombinator.com