Bug 1550 - Move from 3DES to AES-256 for private key encryption
Summary: Move from 3DES to AES-256 for private key encryption
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh-keygen (show other bugs)
Version: 5.1p1
Hardware: All All
: P2 enhancement
Assignee: Assigned to nobody
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2009-01-23 07:03 AEDT by Jim Knoble
Modified: 2010-04-16 15:50 AEST (History)
1 user (show)

See Also:


Attachments
Patch from Damien Miller to enable AES-256 in ssh-keygen (2.27 KB, patch)
2009-01-23 07:03 AEDT, Jim Knoble
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Knoble 2009-01-23 07:03:40 AEDT
Created attachment 1597 [details]
Patch from Damien Miller to enable AES-256 in ssh-keygen

Date: Tue, 20 Jan 2009 01:06:35 -0500
From: Jim Knoble <jmknoble@pobox.com>
To: OpenSSH Devel <openssh-unix-dev@mindrot.org>
Subject: OpenSSH private key encryption: time for AES?
Message-ID: <20090120060635.GA29074@crawfish.ais.com>
Mail-Followup-To: OpenSSH Devel <openssh-unix-dev@mindrot.org>

Hi, all.

So, in reviewing my OpenSSH keypairs and evaluating the size my RSA keys
should be, i realized that, if i update my 2048-bit keypairs to 4096
bits, it really doesn't matter that much, because they're still
only encrypted with 3DES, which provides an effective 112 bits of
symmetric encryption strength:

    $ head -4 ~/.ssh/id_rsa
    -----BEGIN RSA PRIVATE KEY-----
    Proc-Type: 4,ENCRYPTED
    DEK-Info: DES-EDE3-CBC,XXXXXXXXXXXXXXXX

    $ 

According to NIST[1][2], a minimum of 112-bit symmetric / 2048-bit
asymmetric keystrength is recommended for protection up until about
2030.  For protection beyond 2030, or for the paranoid, larger keysizes
are recommended.  Other recommendations (e.g., those of ECRYPT) vary in
how long 112/2048-bit encryption should last.

With that in mind ... how can i encrypt my 4096-bit SSH RSA keypair with
something like AES-128, AES-256, or Twofish instead of 3DES and still
use it with OpenSSH?  Can ssh-add read (unencrypted) key data from stdin?

____________________
[1] http://csrc.nist.gov/groups/ST/toolkit/key_management.html
[2] http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-57Part1_3-8-07.pdf
Comment 1 Jim Knoble 2009-01-23 07:52:35 AEDT
Date: Tue, 20 Jan 2009 20:42:38 -0500
From: Jim Knoble <jmknoble@pobox.com>
To: OpenSSH Devel <openssh-unix-dev@mindrot.org>
Subject: Re: OpenSSH private key encryption: time for AES?
Message-ID: <20090121014237.GD29074@crawfish.ais.com>
Mail-Followup-To: OpenSSH Devel <openssh-unix-dev@mindrot.org>
References: <20090120060635.GA29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901201822540.5492@fuyu.mindrot.org>
In-Reply-To: <alpine.BSO.1.10.0901201822540.5492@fuyu.mindrot.org>

Circa 2009-01-20 02:30 dixit Damien Miller:

: On Tue, 20 Jan 2009, Jim Knoble wrote:
: 
: > [...]how can i encrypt my 4096-bit SSH RSA keypair with
: > something like AES-128, AES-256, or Twofish instead of 3DES and still
: > use it with OpenSSH?  Can ssh-add read (unencrypted) key data from stdin?

Experimentation has shown that the following will add a key to a running
ssh-agent (OpenSSH_4.6p1, Ubuntu 7.10):

    $ cat id_rsa-unencrypted |ssh-add /dev/stdin
    $ ssh-add -l |fgrep /dev/stdin
    2048 xx:xx:xx:...:xx:xx:xx /dev/stdin (RSA)
    $ 

However, the following will not remove the key from the agent:

    $ cat id_rsa-unencrypted |ssh-add -d /dev/stdin
    Bad key file /dev/stdin
    $ 

If both operations worked, then one could use an external
encryption/decryption facility with one's private keys, e.g.:

    openssl enc -d -in ~/.ssh/id_rsa -aes-256-cbc |ssh-add /dev/stdin

(although it would take a passphrase to remove a key from ssh-agent).

: If you want to change it then you can do something like [a one-liner
: change to authfile.c]. It probably wouldn't hurt to change - new
: installations will still be able to read old keys

It would be nice for newer OpenSSH to be able to produce private keys
usable by older OpenSSH as well.

Any chance of an option in ssh-keygen to specify the cipher?  E.g.:

    # Use '-E' with any of: 3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc
    ssh-keygen -t rsa -E aes256-cbc

Alternatively:

    # Encrypt with AES-256:
    ssh-keygen -t rsa -A

    # Encrypt with 3DES:
    ssh-keygen -t rsa -3

    # Use default encryption:
    ssh-keygen -t rsa

Finally:

    # Encrypt with AES-256:
    ssh-keygen -t rsa

    # Encrypt with 3DES ('-O' for "old"):
    ssh-keygen -t rsa -O:1

Cheers,
jim

-- 
jim knoble  |  jmknoble@pobox.com  |  http://www.pobox.com/~jmknoble/
Comment 2 Jim Knoble 2009-01-23 07:54:11 AEDT
Date: Wed, 21 Jan 2009 15:16:31 +1100 (EST)
From: Damien Miller <djm@mindrot.org>
To: Jim Knoble <jmknoble@pobox.com>
Subject: Re: OpenSSH private key encryption: time for AES?
In-Reply-To: <20090121014237.GD29074@crawfish.ais.com>
Message-ID: <alpine.BSO.1.10.0901211509560.5581@fuyu.mindrot.org>
References: <20090120060635.GA29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901201822540.5492@fuyu.mindrot.org>
 <20090121014237.GD29074@crawfish.ais.com>
Cc: OpenSSH Devel <openssh-unix-dev@mindrot.org>

On Tue, 20 Jan 2009, Jim Knoble wrote:

> Circa 2009-01-20 02:30 dixit Damien Miller:
> 
> : On Tue, 20 Jan 2009, Jim Knoble wrote:
> : 
> : > [...]how can i encrypt my 4096-bit SSH RSA keypair with
> : > something like AES-128, AES-256, or Twofish instead of 3DES and still
> : > use it with OpenSSH?  Can ssh-add read (unencrypted) key data from stdin?
> 
> Experimentation has shown that the following will add a key to a running
> ssh-agent (OpenSSH_4.6p1, Ubuntu 7.10):
> 
>     $ cat id_rsa-unencrypted |ssh-add /dev/stdin
>     $ ssh-add -l |fgrep /dev/stdin
>     2048 xx:xx:xx:...:xx:xx:xx /dev/stdin (RSA)
>     $ 
> 
> However, the following will not remove the key from the agent:
> 
>     $ cat id_rsa-unencrypted |ssh-add -d /dev/stdin
>     Bad key file /dev/stdin
>     $ 

Does that work without the patch? I don't think it would even with
the current cipher because it needs to reread the file IIRC.

> If both operations worked, then one could use an external
> encryption/decryption facility with one's private keys, e.g.:
> 
>     openssl enc -d -in ~/.ssh/id_rsa -aes-256-cbc |ssh-add /dev/stdin
> 
> (although it would take a passphrase to remove a key from ssh-agent).

Wouldn't this just require the former to work? You'd be passing keys
to ssh-agent in unencrypted form always, no?

> : If you want to change it then you can do something like [a one-liner
> : change to authfile.c]. It probably wouldn't hurt to change - new
> : installations will still be able to read old keys
> 
> It would be nice for newer OpenSSH to be able to produce private keys
> usable by older OpenSSH as well.

The key encryption for SSH protocol 2 keys is done by OpenSSL's PEM
functions, so AES should be supported by any OpenSSL version that supports
AES in PEM. IIRC this has been supported for a number of years.

> Any chance of an option in ssh-keygen to specify the cipher?  E.g.:

No, I think that would be a microknob that add little value, and ssh-add
has waaaay to many buttons already.

If we change then it should be to the best encryption that is supported by
widely deployed SSL/OpenSSH versions.

-d
Comment 3 Jim Knoble 2009-01-23 07:54:39 AEDT
Message-ID: <4976A70C.2020305@zip.com.au>
Date: Wed, 21 Jan 2009 15:39:40 +1100
From: Darren Tucker <dtucker@zip.com.au>
To: Damien Miller <djm@mindrot.org>
Subject: Re: OpenSSH private key encryption: time for AES?
References: <20090120060635.GA29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901201822540.5492@fuyu.mindrot.org>
 <20090121014237.GD29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901211509560.5581@fuyu.mindrot.org>
In-Reply-To: <alpine.BSO.1.10.0901211509560.5581@fuyu.mindrot.org>
Cc: Jim Knoble <jmknoble@pobox.com>, OpenSSH Devel
 <openssh-unix-dev@mindrot.org>

Damien Miller wrote:
[...]
> If we change then it should be to the best encryption that is supported by
> widely deployed SSL/OpenSSH versions.

Don't forget some versions of the Solaris 10 OpenSSL package cripple all 
ciphers with a key length >128 bits.  We work around that for the SSH 
ciphers but that's not going to help for the OpenSSL PEM functions.

-- 
Darren Tucker (dtucker at zip.com.au)
Comment 4 Jim Knoble 2009-01-23 07:55:03 AEDT
Message-ID: <4976A70C.2020305@zip.com.au>
Date: Wed, 21 Jan 2009 15:39:40 +1100
From: Darren Tucker <dtucker@zip.com.au>
To: Damien Miller <djm@mindrot.org>
Subject: Re: OpenSSH private key encryption: time for AES?
References: <20090120060635.GA29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901201822540.5492@fuyu.mindrot.org>
 <20090121014237.GD29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901211509560.5581@fuyu.mindrot.org>
In-Reply-To: <alpine.BSO.1.10.0901211509560.5581@fuyu.mindrot.org>
Cc: Jim Knoble <jmknoble@pobox.com>, OpenSSH Devel
 <openssh-unix-dev@mindrot.org>

Damien Miller wrote:
[...]
> If we change then it should be to the best encryption that is supported by
> widely deployed SSL/OpenSSH versions.

Don't forget some versions of the Solaris 10 OpenSSL package cripple all 
ciphers with a key length >128 bits.  We work around that for the SSH 
ciphers but that's not going to help for the OpenSSL PEM functions.

-- 
Darren Tucker (dtucker at zip.com.au)
Comment 5 Jim Knoble 2009-01-23 07:56:07 AEDT
Date: Wed, 21 Jan 2009 16:01:35 +1100 (EST)
From: Damien Miller <djm@mindrot.org>
To: Darren Tucker <dtucker@zip.com.au>
Subject: Re: OpenSSH private key encryption: time for AES?
In-Reply-To: <4976A70C.2020305@zip.com.au>
Message-ID: <alpine.BSO.1.10.0901211556540.5581@fuyu.mindrot.org>
References: <20090120060635.GA29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901201822540.5492@fuyu.mindrot.org>
 <20090121014237.GD29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901211509560.5581@fuyu.mindrot.org>
 <4976A70C.2020305@zip.com.au>
Cc: Jim Knoble <jmknoble@pobox.com>, OpenSSH Devel
 <openssh-unix-dev@mindrot.org>

On Wed, 21 Jan 2009, Darren Tucker wrote:

> Damien Miller wrote:
> [...]
> > If we change then it should be to the best encryption that is supported by
> > widely deployed SSL/OpenSSH versions.
> 
> Don't forget some versions of the Solaris 10 OpenSSL package cripple all 
> ciphers with a key length >128 bits.  We work around that for the SSH 
> ciphers but that's not going to help for the OpenSSL PEM functions.

Shouldn't this Just Work with our replacement EVP_aes_256_cbc in
cipher-aes.c? We already switch it on for the OPENSSL_LOBOTOMISED_AES
case (Obviously it would need to be tested...)

-d
Comment 6 Jim Knoble 2009-01-23 07:56:39 AEDT
Date: Thu, 22 Jan 2009 14:49:01 -0500
From: Jim Knoble <jmknoble@pobox.com>
To: OpenSSH Devel <openssh-unix-dev@mindrot.org>
Subject: Re: OpenSSH private key encryption: time for AES?
Message-ID: <20090122194901.GB22282@crawfish.ais.com>
Mail-Followup-To: OpenSSH Devel <openssh-unix-dev@mindrot.org>
References: <20090120060635.GA29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901201822540.5492@fuyu.mindrot.org>
 <20090121014237.GD29074@crawfish.ais.com>
 <alpine.BSO.1.10.0901211509560.5581@fuyu.mindrot.org>
In-Reply-To: <alpine.BSO.1.10.0901211509560.5581@fuyu.mindrot.org>

Circa 2009-01-20 23:16 dixit Damien Miller:

: On Tue, 20 Jan 2009, Jim Knoble wrote:
: 
: >     $ cat id_rsa-unencrypted |ssh-add /dev/stdin
: >     $ ssh-add -l |fgrep /dev/stdin
: >     2048 xx:xx:xx:...:xx:xx:xx /dev/stdin (RSA)
: >     $ 
: 
: Does that work without the patch? I don't think it would even with
: the current cipher because it needs to reread the file IIRC.

It's an unpatched ssh-keygen (OpenSSH_4.6p1 Debian-5ubuntu0.6, OpenSSL
0.9.8e 23 Feb 2007).

: > If both operations worked, then one could use an external
: > encryption/decryption facility with one's private keys, e.g.:
: > 
: >     openssl enc -d -in ~/.ssh/id_rsa -aes-256-cbc |ssh-add /dev/stdin
: > 
: > (although it would take a passphrase to remove a key from ssh-agent).
: 
: Wouldn't this just require the former to work? You'd be passing keys
: to ssh-agent in unencrypted form always, no?

Not sure i understand.  The only decryption would happen in the
'openssl | ssh-add' pipeline.  In order to know which key to remove,
ssh-add would need to read the unencrypted key, which would only be
available by decrypting it in the pipeline, supplying a passphrase to
the 'openssl' command.  Currently, 'ssh-add -d' doesn't require a
passphrase for an OpenSSH-encrypted private key.

I like the flexibility of being able to use stdin with ssh-add (and i
would prefer 'ssh-add -' rather than 'ssh-add /dev/stdin', but
whatever).  However, all the above may be moot in light of the
discussion further below.

: The key encryption for SSH protocol 2 keys is done by OpenSSL's PEM
: functions, so AES should be supported by any OpenSSL version that supports
: AES in PEM. IIRC this has been supported for a number of years.

If older OpenSSH (to a point) would "just work" reading private keys
encrypted with AES-256, then that's fantastic, and no need for any
further options to ssh-keygen.

: If we change then it should be to the best encryption that is supported by
: widely deployed SSL/OpenSSH versions.

Agreed.  Private keys are short, and even if decryption happens
frequently, it takes much longer to enter a passphrase than to decrypt
the key (and both decryption and passphrase can be mitigated via
ssh-agent).

-- 
jim knoble  |  jmknoble@pobox.com  |  http://www.pobox.com/~jmknoble/
Comment 7 Damien Miller 2009-11-10 13:14:32 AEDT
We now use AES-128 for private key encryption on systems that use OpenSSL 0.9.7 and greater. This will be in OpenSSH 5.4.
Comment 8 Damien Miller 2010-04-16 15:50:55 AEST
Mass move of bugs RESOLVED->CLOSED following the release of openssh-5.5p1