Description
What version of Go are you using (go version
)?
$ go version: 1.18
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env
)?
$ go env: all
What did you do?
Using FiloSottile age cli tool under the conditions listed, an error was encountered:
age version: v1.0.0
ssh key used (With Passphrase): ssh-keygen -t ed25519 -f age-ssh -a 100 -Z "chacha20-poly1305@openssh.com"
$ age -d -i age-ssh test.txt.age > test_decrypted.txt $ age: error: reading "age-ssh": malformed SSH identity in "age-ssh": ssh: parse error in message type 0
For further details please see this issue: FiloSottile/age#407
Narrowing down the problem
I have investigated some more and found some conditions under which the problem occurs:
The problem does not occur with keys generated like this:
ssh-keygen -f key -t ed25519 -Z 3des-cbc (with password)
ssh-keygen -f key -t ed25519 -Z aes128-cbc (with password)
ssh-keygen -f key -t ed25519 -Z aes192-cbc (with password)
ssh-keygen -f key -t ed25519 -Z aes256-cbc (with password)
ssh-keygen -f key -t ed25519 -Z aes128-ctr (with password)
ssh-keygen -f key -t ed25519 -Z aes192-ctr (with password)
ssh-keygen -f key -t ed25519 -Z aes256-ctr (with password)
ssh-keygen -f key -Z aes256-ctr (with password)
ssh-keygen -f key -Z aes256-ctr (without password)
ssh-keygen -f key -Z aes128-gcm@openssh.com (without password)
ssh-keygen -f key -Z aes256-gcm@openssh.com (without password)
ssh-keygen -f key -Z chacha20-poly1305@openssh.com (without password)
The problem does occur with keys generated like this:
ssh-keygen -f key -t ed25519 -Z aes128-gcm@openssh.com (with password)
ssh-keygen -f key -t ed25519 -Z aes256-gcm@openssh.com (with password)
ssh-keygen -f key -t ed25519 -Z chacha20-poly1305@openssh.com (with password)
ssh-keygen -f key -Z chacha20-poly1305@openssh.com (with password)
It seems to me like the problem only occurs when using the ciphers aes128-gcm@openssh.com, aes256-gcm@openssh.com and chacha20-poly1305@openssh.com and only when using a password protected key. The type of key seems to be irrelevant.
What did you expect to see?
A decrypted file with no cli errors
What did you see instead?
The error message mentioned above instead
Note: Encryption seemed to work fine in this instance