pull down to refresh

Privacy Tip: GPG - decrypting signed messages from standard input fails.
431 sats \ 4 comments \ @denationalized 6 Mar privacy freebie
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.
write
preview
related posts
100 sats \ 1 reply \ @ek 6 Mar freebie
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.
5 sats \ 1 reply \ @Zenul_Abidin 6 Mar
shred does not work at all on journalled file systems like NTFS and ext4.
reply
0 sats \ 0 replies \ @denationalized OP 6 Mar
It's been a while since I've been using ext4 on all my systems. Is there then any tool that works?
reply