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.

Sign up for GitHub

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

Jump to bottom

Inspect encrypted file details #56

Open
wgslr opened this issue Dec 30, 2019 · 4 comments · May be fixed by #501
Open

Inspect encrypted file details #56

wgslr opened this issue Dec 30, 2019 · 4 comments · May be fixed by #501
Labels
CLI Go API new UI surface

Comments

@wgslr
Copy link

wgslr commented Dec 30, 2019 •
edited

What were you trying to do

Identify file's recipients, or at least how many recipients there are.

What happened

I created an ascii armored encrypted file. age gives no way to list its recipients, as it does in the binary format (excluding some bash magic relying on the knowledge that the PEM uses base64).

$ age-keygen -o key.txt
Public key: age13u320nw4pv6pv7qrve2epr4r7233ms2x68r3y3tt653nyvg5y3jst3apxw
[0]$ echo 'Hello age' | age -a -r 'age13u320nw4pv6pv7qrve2epr4r7233ms2x68r3y3tt653nyvg5y3jst3apxw' -o encrypted.age.ascii
[0]$ cat encrypted.age.ascii
-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSAyUElIMVBpZThuVkh0WDVZ
TUwrSmxuNk1xZFI1dHliNy9Nd0ptZ0UrOVUwCi8wRzc0djRwemZHanJGTGhNb0pB
M0NQTzFQUzFzNEtpclIxeTh2ZkFwR0kKLS0tIFMxUjdZczEyVzZBczNvTGJmZ1VN
Z1hoMWxVOHEwcm40TnZ1VWcvRGM4R0kKQASOAFMfE0DMdj++onPwdeByjMGRP6Sj
3PbGzfjpktCw9HJ14r+qX9B/
-----END AGE ENCRYPTED FILE-----
[0]$ tail -n +2 encrypted.age.ascii | base64 -d
age-encryption.org/v1
-> X25519 2PIH1Pie8nVHtX5YML+Jln6MqdR5tyb7/MwJmgE+9U0
/0G74v4pzfGjrFLhMoJA3CPO1PS1s4KirR1y8vfApGI
--- S1R7Ys12W6As3oLbfgUMgXh1lU8q0rn4NvuUg/Dc8GI
@�S@�v?��s�u�r���?���������а�ru⿪_�base64: invalid input

As a matter of fact, a pretty listing of recipients would also be useful for non-armored files, if it could present the files in the same format as originially (e.g. to visually match/grep ssh pubkey to one of the files in ~/.ssh/id_rsa). And be a good follow up for the error message "Error: no identity matched a recipient".

Side note - confusing feature set of beta

By browsing this repo's issues, the mailing list and the age specification, I encountered various potential methods of storing the keys and specifying recipients (the ~/.config/age/keys.txt path, recipient's github username, providing https url of the keys). None of them seemed to work. It would be nice for the repo's readme to be more explicit about which parts are NOT implemented in the current version.
@codesoap codesoap mentioned this issue Jan 9, 2021
Closed
@codesoap
Copy link
Contributor

codesoap commented Jan 10, 2021 •
edited

Disclaimer: I am not a cryptographer, so maybe I misunderstood the spec.

Looking at the spec, I think it's impossible to do this. The best that could be done is to tell how many recipients there are, but is this really useful?

For example: The spec says, that an age reciepient (X25519) stanza is composed like this:

-> X25519 encode(X25519(ephemeral secret, basepoint))
encrypt[HKDF[salt, label](X25519(ephemeral secret, public key))](file key)

You can see that the public key is only used (after some transformation) to encrypt the file key. I think it is thus impossible to get back the public key from that. It's probably (I'm not sure) even impossible to tell if the file was encrypted for a given public key. I would guess, that this is an intended security feature: No third party should be able to tell for whom a file was encrypted.

@FiloSottile
Copy link
Owner

FiloSottile commented Apr 19, 2021 •
edited

We can't print what recipients a file is encrypted to, but there should be a way to get a text/JSON output with number and types of recipients, header version, and file size. It would work for both armored and binary files.

@FiloSottile FiloSottile changed the title UX: no way of inspecting ascii armored files Inspect encrypted file details Apr 19, 2021
@jamespwilliams jamespwilliams linked a pull request Apr 30, 2023 that will close this issue
Open
@dtscd
Copy link

dtscd commented Sep 8, 2023

It would be nice to be able to find the file size, at least in the Go API, without needing to read the full file. I would like to decrypt a file and stream the raw file out, but use content length=N prefix. It seems like this should be possible by reading the header and knowing the encrypted file size.

@codesoap
Copy link
Contributor

While writing another client for age, I've encountered another application for something like this: If a user tries to decrypt an age file with a password, that was not encrypted with a password, the error from the age library tells the user that the password was wrong.

If the age library gave me some way to see if scrypt was even used during encryption, I could tell the user, whether there is even a point in trying other passwords.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CLI Go API new UI surface
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add --inspect flag jamespwilliams/age
4 participants
@FiloSottile @wgslr @codesoap @dtscd