You have just set up your 2FA with your private GPG key at a website such as Archetyp. Next time after introducing your login and password you will be asked to complete the authentication process by decrypting a GPG message and act according to the instructions that it provides. Seeing such a message you might think: I am not going to store this throway message lest I forget to shred it. And so you proceed to decrypt it in your terminal by running:
gpg -d
and pasting the copied message to your stdin. In case of authenticating at Archetyp that would fail (GPG would just annoyingly pause on you) because such message is signed. gpg -d without the path to the encrypted file is great for decrypting messages only if they are not signed, otherwise it will produce no input. Such behaviour of GPG is also a useful hint at the possibility of dealing with a signed message. With signed message you need to paste it into a text file and then specify the path to the file to be decrypted. I wrote a Bash script that implements this along with subsequent shredding of the file:
#!/bin/bash decrypt_file() { echo "The path to the file to be decrypted?" read file gpg -d ${file} echo "Deleting ${file}?[Y/b]";read ch if [[ "$ch" == 'y' ]]; then shred -u "${file}" fi echo "${file} has just got decrypted." } decrypt_file
P.S. I think that Archetyp's wiki is a good educational resource that a beginner user of public key encryption tools might benefit from whether they are or are not into drugs.
100 sats \ 1 reply \ @ek 6 Mar
Bold of you to link to a DNM
gpg -d without the path to the encrypted file is great for decrypting messages only if they are not signed, otherwise it will produce no input
That is not my experience. gpg -d works fine with standard input. It doesn't distinguish between signed and unsigned. At least it's not mentioned in the documentation:
--decrypt -d Decrypt the file given on the command line (or STDIN if no file is specified) and write it to STDOUT (or the file specified with --output). If the decrypted file is signed, the signature is also verified. This command differs from the default operation, as it never writes to the filename which is included in the file and it rejects files that don't begin with an encrypted message.
I think you forgot to enter CTRL+D which results in a end-of-file character:
Input from a terminal never really "ends" (unless the device is disconnected), but it is useful to enter more than one "file" into a terminal, so a key sequence is reserved to indicate end of input. In UNIX the translation of the keystroke to EOF is performed by the terminal driver, so a program does not need to distinguish terminals from other input files. By default, the driver converts a Control-D character at the start of a line into an end-of-file indicator.
-- wikipedia.org, End-of-file
That's not intuitive but required to let the program know that your input is finished and it can start processing.
I would be interested if that was indeed your issue.
reply
That is not my experience. gpg -d works fine with standard input. It doesn't distinguish between signed and unsigned.
You are right with CTRL-D but GPG's behaviour differs based on whether it deals with signed or unsigned messages. When I paste an unsigned message, having first run gpg -d, GPG decrypts the message without me having to press anything, I get something like that:
gpg: encrypted with 4096-bit RSA key, ID 2**************F, created 2024-03-01 "******@******" first line of the message second (last) line of the message
Having given me the decrypted message, then GPG just hangs on me. Yes, it is true that then I need to press CTRL-D, or CTRL-C for that matter, because GPG just hangs on me. My bad - not knowing what was happening I was just pressing CTRL-C. But with the signed message given to the stdin GPG behaves differently: the only output it gives me straight away is a note on the metadata without the actual content of the message:
encrypted with 4096-bit RSA key, ID 2**************F, created 2024-03-01 "*****@******"
When I then press CTRL-D it would give me the content of the message and the information about the signature:
first line of the message second (last) line of the message gpg: Signature made Thu 07 Mar 2024 08:13:41 CET gpg: using RSA key 2*******************************F gpg: Good signature from "*******@*******" [ultimate]
Do you have the same behaviour on your side when you decrypt an unsigned message?
reply
shred does not work at all on journalled file systems like NTFS and ext4.
reply
It's been a while since I've been using ext4 on all my systems. Is there then any tool that works?
reply