When you receive a PGP message encrypted with your key, your PGP software can decrypt it because the message itself is encrypted with a one-time use random key and that random key is encrypted with your own key. Therefore, if you can get the random key ("session key" or "secret key"), then you can share it (and the original message) to prove to someone else what the original message said. This is what I need to do. I have been unable to find commands I can use in Windows or Linux to recover this random key. Does anyone know how to get it from the PGP message?
I'd also like to learn how to improve my search strategy because I believe the answer is already on the Internet and I just didn't search for the right keywords to find it.
echo '-----BEGIN PGP MESSAGE [...]' | gpg --show-session-key
It's okay if your PGP message spans multiple lines. You can paste it in and the presence of the first single quote causes the CLI to continue your input at the line breaks.
In Windows subsystem for Linux (aka WSL), you can use gpg to do this. One common problem with gpg is that it assumes it has a terminal connection (which is probably true) and that GPG_TTY is an environment variable that points to that connection (which might be false). The result of trying something in this case will produce Inappropriate ioctl for device and you can fix that with the following command: export GPG_TTY=$(tty)
You have to make sure the key you use to decrypt the message is in the keyring of the system you're using. I've been using Kleopatra in Windows and forgot that the keyring it uses is NOT shared with WSL, so I had to gpg --import [filename of my key] and enter my passphrase.
Once all that works, you'll get output that contains something like:
gpg: session key: '3:541FE563...
which you can use as described at https://security.stackexchange.com/questions/115231/how-to-decrypt-a-message-using-only-session-key to share the contents of the encrypted message without divulging your own private key. Thanks to Alex of Localmonero.com (aka Agoradesk.com) for helping me figure this out.
Related
I'd like to generate a public/private keypair from the command line which I can use for local testing with a NEAR Protocol account. How is this done?
There are multiple ways to generate keys for custody purposes. See custody docs for examples. From the docs:
Generally, any software that can produce valid ed25519 key pair can be used to generate the keys.
To generate a straightforward keypair (see format requirements), where both public and private key will be available in plaintext to you, you can use the near command line tools to output a keypair for an account (once you've installed them):
NEAR_ENV=mainnet near generate-key your-account-name
This creates a json keypair at ~/.near-credentials/mainnet/your-account-name.json
mainnet is the network this will be used with by default and also the folder within which the JSON file will live.
If you don't specify an account, one will be automatically generated, for example:
NEAR_ENV=mainnet near generate-key
Key pair with ed25519:6okNNRWxvWAyWMYxmgBQ2EWPyRm1FfppgXXWJELrFLXh public key for an account "5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680"
If you peek into the generated JSON file, which lives at ``~/.near-credentials/mainnet/5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680.json`, it looks like this:
{"account_id":"5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680","public_key":"ed25519:6okNNRWxvWAyWMYxmgBQ2EWPyRm1FfppgXXWJELrFLXh","private_key":"ed25519:5NDP1t4JijZHZzGnEkz3dancSWsLG3Gjss4WPXNPiHWNtdtvVJttW9uPqvxKMCwwPgtYvTxzQqDE7mSN72wXsMcK"}
The keypair generated each time is different, but the JSON files persist. And, yes, the keypair displayed above is purely for demonstration purposes and isn't linked to anything interesting :) (don't go sharing real keypairs on the internet, folks).
Troubeshooting -- you may need to double check your permissions to create or write to the ~/.near-credentials directory to make this work properly.
I have interest in using GPG to sign and encrypt messages, but the GPG keys are not in my private or public keyrings, they are in separate files. Is there any way to sign and encrypt messages with keys in files, rather than using keys in my keyring?
I've looked at https://superuser.com/questions/450759/simple-pgp-encryption-in-one-step/450760#450760, but it involves creating a temporary keyring in a temporary directory, and that's not quite what I want to do.
I've also looked at In-memory GPG signing (or possibly using a temporary keyring), but wants an in-memory key...
I'd like to give the highest trust level to a certificate. I need to do so, as this certificate is mine but I don't have exported it before formatting my PC.
I have downloaded it from a public key server and I have my private key saved in KeePass, but I don't know what to do next.
I'm sorry I cannot tell you how to do it in Kleopatra, but it is rather easy on the command line.
If you haven't imported the private key yet, save it to a file (let's say, key.pgp, name and extension don't matter). Now run gpg --import <key.pgp. Your key should be listed using gpg -K now.
For setting trust (the highest trust level in OpenPGP is "ultimate", which is usually only applied to your own certificates, as you want to do in this case), run gpg --edit-key [key-id] (printed in gpg -K above). In the edit key menu, run trust; and enter 5 (followed by Return for "I trust ultimately". Confirm with y (again followed by Return), and finally run save to store the modified key and quit GnuPG.
I successfully put my private key at a place where git finds it when it connects to github.
(like this https://serverfault.com/questions/194567/how-to-i-tell-git-for-windows-where-to-find-my-private-rsa-key/198691#198691 )
But when I try to sign a tag, this default magic seems not to apply. The brilliant git community book talks about an gpg-key-id, but I created my keys with puttygen, and seem not to have such an id.
So, how can I tell git a Windows machine that the key it shall use resides at ~/.ssh/id_rsa ?
Thank you, Falko
To sign a tag you need a GPG/PGP ID and not a SSH id. The SSH id is used to encrypt the connection and identify yourself to the server.
The GPG works in general similar how ever there is a kind of "profile" linked to your public gpg key. To get started on with GPG on windows gpg3win is a good place to look. Also the Wikipedia entries on GPG and PGP are good places to get some insight regarding this topic.
how can I tell git a Windows machine that the key it shall use resides at ~/.ssh/id_rsa
You need to define ~, ie HOME (which isn't a variable defined by default on Windows. HOMEPATH or USERPROFILE are).
See for instance "Auth fails on Windows XP with git and tortoisegit", where HOME is defined to a complete non-default path (ie not HOMEPATH)
I'd like to write a shell script that does something like the following
while read line; do
echo $line
done<input.txt | ssh > output.txt
This is a bit pseudo codey at the moment (the original is at work), but you should be able to tell what it's doing. For simple applications this works a treat, but ssh checks the input to see whether it's stdin is a terminal.
Is there a way to fool ssh into thinking that the contents of my piped loop are a terminal rather than a pipe?
EDIT : Sorry for not adding this originally, this is intended to allow ssh to log in via the shell script (answering the password prompt)
ssh -t -t will do what you want - this tells ssh to allocate a pseudo terminal no matter whether it is actually running in one.
Update
This problem (after updating your question and various comments, it became clear you are looking for a way to conveniently get public key encryption into place) could perhaps be solved by 'thinking upside down'.
Instead of trying very hard to get your clients public key onto a server that doesn't yet authenticate the client, you can try to receive an authenticated identity (private key) from that server.
Simple terms: generate a keypair on the server instead of the client, and then find a way to get the keypair on the client. The server can put the public key in it's authorized_keys in advance, so the client can connect right away.
Chances are that
the problem of getting the key across is more easily solved (you could even use a 'group' key for access from various clients)
if a less-secure mechanism is chosen (convenience over security) at least only the security of the client is reduced, not as-much that of the server (directly).
Original answer:
Short answer: Nope. (it would be a security hole for ssh, because ssh 'trusts' the tty for password entry, and the tty only)
Long answer, you could try to subvert/creatively use a terminal emulator (look at script/scriptreplay for inspiration).
Why would you want to do it?