ItsDrike/itsdrike.com
1
0
Fork 0
mirror of https://github.com/ItsDrike/itsdrike.com.git synced 2024-11-10 05:59:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix -r meaning in gnupg post

Browse source
This commit is contained in:
ItsDrike 2022-04-12 19:20:42 +02:00
parent 61b1cffd15
commit ac40624c65
No known key found for this signature in database
GPG key ID: B014E761034AF742
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
content/posts/gnupg/index.md
View file

@ -265,18 +265,18 @@ To encrypt a file, we can use this command:
gpg --armor --encrypt -r [key-id] my_plaintext_file.txt gpg --armor --encrypt -r [key-id] my_plaintext_file.txt
``` ```
Here, the `[key-id]` points to the recipient's public key id, so either an email, or key's ID directly. This is NOT Here, the `[key-id]` points to the recipient's public key id (`-r` stands for recipient), so either an email, or key's
your key id, it's the recipient's one! ID directly. This is NOT your key id, it's the recipient's one!
This will generate an encrypted file with the same name as the original, but with an additional extension of `.asc`, This will generate an encrypted file with the same name as the original, but with an additional extension of `.asc`,
this extension means that we used ASCII readable characters in the encrypted file, instead of raw bytes. If you don't this extension means that we used ASCII readable characters in the encrypted file, instead of raw bytes. If you don't
need this, you can leave out the `--armor` flag, and instead get a file that ends with `.gpg` and contains the raw need this, you can leave out the `--armor` flag, and instead get a file that ends with `.gpg` and contains the raw
bytes after encryption. bytes after encryption.
The use of `-r` flag is also optional, and using it will allow the encrypted file to also be decrypted by us, not just We can also include multiple recipients by adding more `-r [key-id]` sequences. With this, we could also include
by the recipient. This is something that we usually want, so that we can actually know what we sent even after deleting our public key, to which we have the private key, allowing us to also be able to decrypt it. By default, if we don't
the file on our side, but if for any reason we wouldn't want to be able to decrypt this later on, leaving out this flag specify our public key in recipients, and the original file was removed, decryption of the original wouldn't be
will ensure that without the recipient's private key, we won't be able to decrypt this file. possible (unless the actual recipient decrypts it for us).
Optionally, if you want to let the recipient know that it was you who encrypted this file, you can also perform signing Optionally, if you want to let the recipient know that it was you who encrypted this file, you can also perform signing
on the encrypted result. You can do this separately, following the signing file section, or you can simply include on the encrypted result. You can do this separately, following the signing file section, or you can simply include