Key generation: pass-a and -o argument?

[timdream]

I couldn't help but notice the suggestion here ask for ssh-keygen -o -a 100 -t ed25519. We are using -t ed25519 but I wonder if -a and -o is really necessary.

[floatingatoll]

ED25519 keys are only compatible with the new key format, so -o is
theoretically redundant, but I personally like that it's present as it
calls attention to "new key format" when trying to debug issues later on.

What value do you propose for -a rather than the current value of
100? Are you encountering technical issues with 100-round keys?

On Sat, Sep 24, 2016 at 8:18 AM, Timothy Guan-tin Chien <
[email protected]> wrote:

I couldn't help but notice the suggestion here
https://blog.g3rt.nl/upgrade-your-ssh-keys.html ask for ssh-keygen -o
-a 100 -t ed25519. We are using -t ed25519 but I wonder if -a and -o is
really necessary.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#68, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFqDHWsJAjbEPm7Nn6NAjbPdcGfVdYAks5qtT86gaJpZM4KFqm9
.

[timdream]

What value do you propose for -a rather than the current value of 100? Are you encountering technical issues with 100-round keys?

@floatingatoll I am not proposing any other values for -a. I was asking if we want to recommend -a 100 as well in our guidelines on key generation.

[gdestuynder]

-o is indeed redundant for ed25519
It's a local protection also.

-o Causes ssh-keygen to save private keys using the new OpenSSH format rather than the more compatible PEM format. The new format has increased resistance to brute-force password cracking but is not supported by versions of OpenSSH prior to 6.5. Ed25519 keys always use the new private key format.

In general, unless there is a really tangible security gain, I'd tend to keep the slightly more compatible option until more tools are aware of the new format (which is to not specify -o for non-ed25519 keys). Just my opinion, of course.

-a is quite similar, as in it is "only" a local protection (it also require -o on non-ed25519). Default is 16 rounds, which is relatively slow (takes up to a second to check the passphrase depending on the machine), 100 is potentially quite slow and seem arbitrary to me.

On my i7 Skylake 6560-U (basically, the fastest U laptop CPU from january 2016), to decrypt it takes (half-scientific method ;-):

16 rounds:

real 0m0.682s

64 rounds:

real 0m1.095s

100 rounds:

real 0m1.400s

128 rounds:

real 0m1.749s

Basically, anything above 64 starts to annoy me significantly on this laptop (its less inconvenient if you've the key in the agent at all times, but then using more rounds starts to bring less benefits.

On a faster machine. I've a quick-and-dirty tool that is probably outdated that tries to estimate how long passphrase X takes to break with resources Z, using known-amount-of-computing-power from the NSA and others, then extrapolating that for safety (https://github.com/gdestuynder/pwgen/)
Even at 180 billion checks per second (as per above, on my laptop its less than 2/second at 16 rounds), a strong-ish passphrase takes practically forever to brute-force. I would like to be corrected if wrong - but I suspect that currently its not practical to brute-force even with enormous computing resources (until the algorithm is pretty much broken).

Due to this, unless your passphrase is really weak, such as "blah" (in which case 100 rounds won't cut it), I would question the need for more than 16 rounds if it's inconveniencing the user.

I wonder what the author of https://blog.g3rt.nl/upgrade-your-ssh-keys.html would say about this.
@gertvdijk, I believe you are the author of that page, do you have any feedback on this? (just opportunistically adding you there, if you're interested in the discussion)

[floatingatoll]

To clarify: When you say "check the passphrase", does the annoying delay
only occur when adding the key to your SSH agent, or does it occur every
time you attempt to use the key in your agent?

• R.

On Mon, Sep 26, 2016 at 3:43 PM, Guillaume Destuynder <
[email protected]> wrote:

-o is indeed redundant for ed25519
It's a local protection also.

-o Causes ssh-keygen to save private keys using the new OpenSSH format
rather than the more compatible PEM format. The new format has increased
resistance to brute-force password cracking but is not supported by
versions of OpenSSH prior to 6.5. Ed25519 keys always use the new private
key format.

In general, unless there is a really tangible security gain, I'd tend to
keep the slightly more compatible option until more tools are aware of the
new format (which is to not specify -o for non-ed25519 keys). Just my
opinion, of course.

-a is quite similar, as in it is "only" a local protection (it also
require -o on non-ed25519). Default is 16 rounds, which is relatively
slow (takes up to a second to check the passphrase depending on the
machine), 100 is potentially quite slow and seem arbitrary to me.

On my i7 Skylake 6560-U (basically, the fastest U laptop CPU from january
2016), to decrypt it takes (half-scientific method ;-):

16 rounds:

real 0m0.682s

64 rounds:

real 0m1.095s

100 rounds:

real 0m1.400s

128 rounds:

real 0m1.749s

Basically, anything above 64 starts to annoy me significantly on this
laptop (its less inconvenient if you've the key in the agent at all times,
but then using more rounds starts to bring less benefits.

On a faster machine. I've a quick-and-dirty tool that is probably outdated
that tries to estimate how long passphrase X takes to break with resources
Z, using known-amount-of-computing-power from the NSA and others, then
extrapolating that for safety (https://github.com/gdestuynder/pwgen/)
Even at 180 billion checks per second (as per above, on my laptop its less
than 2/second at 16 rounds), a strong-ish passphrase takes practically
forever to brute-force. I would like to be corrected if wrong - but I
suspect that currently its not practical to brute-force even with enormous
computing resources (until the algorithm is pretty much broken).

Due to this, unless your passphrase is really weak, such as "blah" (in
which case 100 rounds won't cut it), I would question the need for more
than 16 rounds if it's inconveniencing the user.

I wonder what the author of https://blog.g3rt.nl/upgrade-
your-ssh-keys.html would say about this.
@gertvdijk https://github.com/gertvdijk, I believe you are the author
of that page, do you have any feedback on why these values were chosen in
your blog post?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#68 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFqDBICAz0_81OwkBlkR0W4faDkc02Mks5quEqcgaJpZM4KFqm9
.

[gdestuynder]

This is every time the key is decrypted, so when you add it to the agent the first time - it then depends on your agent settings. If the agent times out after 60s for it means every time after 60s. If it never expires, then it's only once.

The agent stores the plaintext private key in memory while unlocked.

[floatingatoll]

The vast majority of users do not run an agent timeout, based on my limited
understanding. I am comfortable with our default suggestion incurring 1
second of delay now and then, with the understanding that people with
extremely short agent timeouts will wait slightly more now and then.

• R.

On Tue, Sep 27, 2016 at 10:47 AM, Guillaume Destuynder <
[email protected]> wrote:

This is every time the key is decrypted, so when you add it to the agent
the first time - it then depends on your agent settings. If the agent times
out after 60s for it means every time after 60s. If it never expires, then
it's only once.

The agent stores the plaintext private key in memory while unlocked.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#68 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFqDK3lMGzQhh8_kOCjqD2WJeIDfY8wks5quVaggaJpZM4KFqm9
.