You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you paste armored text into GUI decrypt tool (whether created with mode encrypt or signcrypt) the GUI will display the decrypted plaintext directly within the GUI.
However, if you instead choose a binary file from the filesystem to decrypt it will always save plaintext back to the filesystem as a file with the .dec (presumably for decrypted) back to the same folder.
This differing treatment can be confusing. I can see how saving the file to the filesystem would be useful for files that are non-textual in nature (e.g. an encrypted .zip or .png), but the heuristic of assuming that ascii armored ciphertext represents something able to be displayed within the GUI won't apply universally.
One possible solution might be to examine the file when it is decrypted (and before displaying or saving it) and checking if it contains only GUI safe characters with a regex and if so display it in the GUI directly whenever possible. This is a much friendlier way of dealing with the output (and likely safer as there won't be a plaintext artifact for the user to cleanup afterwards).
As an example here is a screenshot of a .jpg file I encrypted and armored. Pasting this armored text results in unpleasant output. I would have to resort to the command line to actually open this file.
If you paste armored text into GUI decrypt tool (whether created with mode encrypt or signcrypt) the GUI will display the decrypted plaintext directly within the GUI.
However, if you instead choose a binary file from the filesystem to decrypt it will always save plaintext back to the filesystem as a file with the
.dec
(presumably for decrypted) back to the same folder.This differing treatment can be confusing. I can see how saving the file to the filesystem would be useful for files that are non-textual in nature (e.g. an encrypted .zip or .png), but the heuristic of assuming that ascii armored ciphertext represents something able to be displayed within the GUI won't apply universally.
One possible solution might be to examine the file when it is decrypted (and before displaying or saving it) and checking if it contains only GUI safe characters with a regex and if so display it in the GUI directly whenever possible. This is a much friendlier way of dealing with the output (and likely safer as there won't be a plaintext artifact for the user to cleanup afterwards).
As an example here is a screenshot of a .jpg file I encrypted and armored. Pasting this armored text results in unpleasant output. I would have to resort to the command line to actually open this file.
keys encrypt -r grempe@github -s grempe@github -a -in testing.jpg -out testing.jpg.enc
https://share.getcloudapp.com/7KuLJekl
The text was updated successfully, but these errors were encountered: