Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

age -d -i does not support aes256-cbc encrypted ed25519 private keys #100

Closed
martinseener opened this issue Feb 12, 2020 · 3 comments · Fixed by #111
Closed

age -d -i does not support aes256-cbc encrypted ed25519 private keys #100

martinseener opened this issue Feb 12, 2020 · 3 comments · Fixed by #111

Comments

@martinseener
Copy link

martinseener commented Feb 12, 2020

Environment

  • OS: Linux Mint 19.3
  • age version: 9fdb125

What were you trying to do

I have encrypted a file using age -r "ssh-ed25519 AAAA..." -o testfile.age testfile and then wanted to decrypt it using age -d -i ~/.ssh/id_ed25519 testfile.age

What happened

age errored that it does not support aes-cbc mode:

Enter passphrase for "/home/myusername/.ssh/id_ed25519": 
Error: failed to decrypt SSH key file: ssh: unknown cipher "aes256-cbc", only supports "aes256-ctr"

I created my key some years ago with ssh-keygen -t ed25519
I expect age to support decrypting aes-cbc as well (128/256bits)

Interesting side note: My RSA private key is encrypted using aes-128-cbc but using it with age works at this point. Not sure why though.

@martinseener martinseener changed the title age -d -i does not support aes256-cbc encrypted private keys age -d -i does not support aes256-cbc encrypted ed25519 private keys Feb 12, 2020
@str4d
Copy link

str4d commented Feb 12, 2020

Looks like the default cipher that ssh-keygen uses to encrypt keys was switched from aes256-cbc to aes256-ctr (issue) in OpenSSH 7.6, released 2017-10-03.

AFAICT those are the only two ciphers that have ever been default for ssh-keygen (for the OpenSSH privkey format, which was introduced in OpenSSH 6.5, released 2014-01-30), so if we support both of those, that will cover basically all encrypted OpenSSH keys.

@RKinsey
Copy link
Contributor

RKinsey commented Mar 18, 2020

Unfortunately, this isn't really fixable from here. x/crypto/ssh explicitly checks for the "aes256-ctr" string and fails otherwise when using passphrase-protected keys. I'll open an issue to see if excluding CBC was intentional.

str4d added a commit to str4d/rage that referenced this issue Mar 21, 2020
When OpenSSH introduced its current encrypted-key format, ssh-keygen
defaulted to "aes256-cbc" for the cipher. This was changed in OpenSSH 7.6
(released 2017-10-03) to "aes256-ctr", and is the same to this day.

Adding support for "aes256-cbc" ensures compatibility with all encrypted
keys generated by ssh-keygen since OpenSSH 6.5 (released 2014-01-30).

See also FiloSottile/age#100
@RKinsey
Copy link
Contributor

RKinsey commented Mar 23, 2020

I submitted a change to fix this to x/crypto, so it's closable once the commit is merged

str4d added a commit to str4d/rage that referenced this issue Mar 23, 2020
When OpenSSH introduced its current encrypted-key format, ssh-keygen
defaulted to "aes256-cbc" for the cipher. This was changed in OpenSSH 7.6
(released 2017-10-03) to "aes256-ctr", and is the same to this day.

Adding support for "aes256-cbc" ensures compatibility with all encrypted
keys generated by ssh-keygen in this format since it was introduced in
OpenSSH 6.5 (released 2014-01-30).

See also FiloSottile/age#100
str4d added a commit to str4d/rage that referenced this issue Mar 23, 2020
When OpenSSH introduced its current encrypted-key format, ssh-keygen
defaulted to "aes256-cbc" for the cipher. This was changed in OpenSSH 7.6
(released 2017-10-03) to "aes256-ctr", and is the same to this day.

Adding support for "aes256-cbc" ensures compatibility with all encrypted
keys generated by ssh-keygen in this format since it was introduced in
OpenSSH 6.5 (released 2014-01-30).

See also FiloSottile/age#100
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants