I am trying to decrypt a file that has been encrypted using 2 recipients (--recipient recipientA#example.com --recipient recipientB#example.com).
However when I try to decrypt the file, it always requests the passphrase of the 1st recipient. When the 1st recipient secret-key isn't part of the key-ring, it will give an error 'secret key not found'.
How can I encrypt a file with multiple recipients so that both can decrypt them without knowing eachother keys & passphrases?
(To me, the question seems simple and a basic feature - but obviously I cannot get it to work)
Thank you in advance!
I ran into this problem today, and found your question looking for the answer. I've seen many merry an example of how to encrypt things for multiple recipients... never saying/showing what will happen when one tries to decrypt that data. Here's what I got:
user#system ~ $ gpg --decrypt filename.pgp
You need a passphrase to unlock the secret key for
user: "SOMEBODY ELSE <somebody_else#example.com>"
2048-bit ELG-E key, ID ABC1234, created 1972-10-29 (main key ID ABC5678)
gpg: Invalid passphrase; please try again ... [I DON'T HAVE *THEIR* PASSPHRASE!]
2 more times... finally...
You need a passphrase to unlock the secret key for
user: "HEY! This is ME! <my_email#example.com>"
2048-bit ELG-E key, ID DEF1234, created 1969-02-03 (main key ID DEF5678)
gpg: encrypted with 2048-bit ELG-E key, ID ABC1234, created 1972-10-29
"NAME <email#example.com>"
gpg: public key decryption failed: bad passphrase
gpg: encrypted with 2048-bit ELG-E key, ID DEF1234, created 1969-02-03
"HEY! This is ME! <my_email#example.com>"
and then the file decrypted fine...
Quick Note: Just to clarify, for security reasons one's passphrase and one's private key should NEVER be given to anyone else. The passphrase is to keep the private key "safe" should it become compromised. One's public key is the only thing that should be shared with others.
I preface this with the fact I currently only have access to version 1.4.2.2, and don't have the ability to test these solutions. Later version have certain options that may well be what's needed. Please try and answer back if any of these work.
--local-user/-u looked promising. In the version I have, --help showed use this user-id to sign or decrypt But when trying it seemed futile, further research revealed a cruel truth: seems the help is wrong, and this is ONLY an option using for "signing".
This post has a likely solution, though I personally find it messy:
gpg --try-all-secrets --passphrase <passphrase here> filename.pgp
--passphrase was apparently added in version 1.4.3. UGH!
EDIT: Perhaps a better (possibly, below) solution is only available in gpg2? gpg2 seems to have --try-secret-key, which if I read correctly, may be what we're both looking for?
I have also faced this problem today and I have solved it by running gpg in batch mode:
/usr/bin/gpg --batch --passphrase "your_passphrase" --verbose --decrypt
Related
With GPGME, how would I check if I can decrypt a given secret with the current keychain.
I can attempt decryption with gpgme_op_decrypt and catch GPG_ERR_NO_SECKEY errors, but this seems non-optimal, nor do I know if this covers all cases.
Is there can_decrypt function, do_we_own_decrypt_key_for_secret or alike?
Also, can I list the secret recipients without decrypting the secret, that could help with this issue.
I'm looking into SOPS as a possible solution for us to encrypt secrets and push them to our repo.
I've been playing around with it and it's exactly what I need, except for a small issue. I'm hoping this is me just not finding the right documentation.
For the sake of simplicity let's say we have 2 AWS accounts, A and B.
In account A we've got:
Our "human" users who will be encrypting/decrypting secrets from their local machines.
KMS key
Role that users from other accounts can assume to use that KMS key.
In account B:
User a Jenkins script will use to decrypt secrets
To encrypt a file with my local user I'm doing:
sops --kms arnofthekey -e -i filename.yaml
And to decrypt it:
sops --kms arnofthekey -d -i filename.yaml
Works like a charm.
If I do it as my Jenkins user:
sops --kms arnOfTheKey+arnOfTheRole -e -i filename.yaml
sops --kms arnOfTheKey+arnOfTheRole -d -i filename.yaml
Everything works like a charm as long as I encrypt/decrypt in the same place.
I then tried to encrypt with Jenkins and decrypt locally. I got an error informing me I'm not allowed to asssume the role Jenkins used. Which is absolutely true.
Here's what I don't understand, the KMS key is the same one in both cases. However, I can see the encrypted file keeps a record of the role. I thought since the key is the same, this should work.
Is there some sort of configuration I'm missing?
Thanks!
Digging a bit more I found an open ticket from a year ago. I guess, at the moment, this is something that can't be done directly with sops.
https://github.com/mozilla/sops/issues/555
The solution I found was allowing my human users to assume the same role Jenkins does. Should've thought about it earlier :)
I am fairly new to PGP encryption. I generated a new key pair last week on a Yubikey, while previously I had only used a private key that I generated on my machine. I use thunderbird enigmail for key management. This is probably a stupid question but I don't actually understand how to encrypt an email using the private key stored on my Yubikey. I can decrypt just fine but can't figure out how to compose an encrypted email from the new key. Using my old key pair, it's automatic - how do I actually encrypt using the right private key? At what point do I enter the Yubikey and pin? (I'm not all that technical and I use encryption for one specific project, so I appreciate dumbing down something that is probably very obvious.)
Using keys generated on a Yubikey is a practically identical process to using your old keys, with one extra step of set up.
To use keys stored on a Yubikey, you need "key stubs" registered on your PGP system. Basically, these are references that tell your PGP software "This private key is located on smartcard number #123456." Once you have the stubs to the keys you need, Enigmail should treat the Yubikey-stored keys like any other PGP key.
I'm only familiar with GnuPG, so specifics may vary, but using GPG you need to
Have a copy of the public key imported to your system from a key server or the like.
Import key stubs from your smart card (in this case, your Yubikey) using:
gpg --card-status
After that, checking your private keyring should reflect that you have stubs pointing to private keys stored on a smart card (denoted by the > after sub). I.E.
gpg --list-secret-keys
----------------------------------------------------
sec# rsa2048 2018-01-02 [C] [expires: 2020-01-02]
ABCDEF123456789ABCDEF123456789ABCDEF1234
uid [ ultimate] My Name (My PGP key) <anAddress#somesite.com>
ssb> rsa2048 2018-01-02 [S] [expires: 2018-12-31]
ssb> rsa2048 2018-01-02 [E] [expires: 2018-12-31]
ssb> rsa2048 2018-01-02 [A] [expires: 2018-12-31]
At this point you can use sub keys of CDEF1234 as if there were on your system. Your PGP software ought to handle checking the card is inserted and dealing with PIN entry.
I am trying to decrypt a set of files with GnuPG, for which I already have the username and password. However, I cannot seem to be able to do so, even though I have generated a new key with the given credentials. When trying to run
gpg --output result.sc --decrypt myFile.sc.xz.gpg
I get:
gpg: encrypted with RSA key, ID 3662FD5E
gpg: decryption failed: No secret key
I am wondering, which are the steps in decrypting with GnuPG? I followed the instructions here http://linoxide.com/security/gpg-comand-linux-how-to-encrypt-and-decrypt-file/, but still did not get it to work. I have no other key given except for these credentials.
You're missing the private key with 3662FD5E.
I have no other key given except for these credentials.
Without this key, you cannot decrypt the file. The password you have might protect the private key, but without the private key, there's definitely no way to decrypt the file (unless in future, a way is found to crack the encryption, but as of now, pretty much all relevant and actually used algorithms in OpenPGP are believed to be secure).
even though I have generated a new key with the given credentials
Keys are generated from random numbers, you cannot generate the same key again, also when using the same user ID and password.
Is it possible to encrypt data, such that it can be decrypted with several different keys?
Example:
I've encrypted data with key1, but I want to be able to decrypt with keys 2, 3, and 4.
Is this possible?
GnuPG does multi-key encryption in standard.
The following command will encrypt doc.txt using the public key for Alice and the public key for Bob. Alice can decrypt using her private key. Bob can also decrypt using his private key.
gpg --encrypt --recipient alice#example.com \
--recipient bob#example.com doc.txt
This feature is detailed in the user guide section entitled "Encrypting and decrypting documents"
Yes it's possible
Yes encryption for multiple recipients is possible. Also it seems logical when you think that you might want to be able to read what you've sent to someone and to do so you need to be in the recipients list.
Command line
Here is how to do it through gpg command line (as described in David Segonds' answer):
gpg --encrypt \
--recipient alice#example.com \
--recipient bob#example.com \
clear-message.txt
GUI client
Your GUI must provide a way to encrypt for several people
Mechanism
There is a question on Information Security, GPG File size with multiple recipients?, that explain the encryption mechanism:
GPG encrypts the file once with a symmetric key, then places a header
identifying the target keypair and an encrypted version of the
symmetric key.
[...] When encrypted to multiple recipients, this
header is placed multiple times providing a uniquely encrypted version
of the same symmetric key for each recipient.
GnuPG and PGP clients in general usually encrypt the actual data with a symmetric key called a "session key". The session key is then encrypted with each "recipient key" (i.e. the ones you specify with -r/--recipient). This is sometimes referred to as a hybrid cipher. Right now, I believe GnuPG by default uses an 256 bit session keys and AES to encrypt the plaintext data to that AES-256 session key, and your recipient keys are your RSA/DSA/ECDSA/etc. assymetric key in this case.
One reason for doing it this way is that symmetric cryptographic algorithms like AES are generally a lot faster than asymmetric ones like RSA. GnuPG thus only has to encrypt ~256 bits (the session key) with RSA, and can use AES to encrypt the data (as large as you want it to be!) with that session key. Intel machines even have a built in instruction, AES-NI, to do some steps of the algorithm in hardware, which makes GnuPG extra snappy at encrypting/decrypting data.
Another reason for doing it this way is that it allows PGP-encrypted documents to be encrypted to multiple parties without having to double the size of the document. Notice that when you specify multiple recipients for an encrypted document (e.g. gpg -ea -r Alice -r Bob -o ciphertext.asc), the encrypted document that gets stored (ciphertext.asc) is not 2x as large as if you had just encrypted it to Alice.
See also the --show-session-key parameter in the gpg man page to be able to decrypt just the session key, for example to allow a third party to decrypt a document that is encrypted to you without having to transfer to them your private key or the plaintext data.
Yes, it's possible. Google "multiparty encryption" for a start.
AFAIK, there are no drop 'em in and use 'em packages for it though.
-- MarkusQ
P.S. For a sketch of how it could be done, consider this. The encrypted message consists of:
the payload, encrypted with a one-time pad
the one time pad, encrypted with key1
the one time pad, encrypted with key2
...
the one time pad, encrypted with keyN
The recipient who hold key i just decrypts their copy of the pad with their key, and then decrypts the payload.
However, this is just a proof that it could be done and would suck as an actual implementation. If at all possible, you should avoid rolling your own encryption. If you don't understand why, you should definitely avoid rolling your own encryption.
-----Edit ------------
If I'm wrong and the Gnu tools do that, use them. But I can't seem to find any information on how to do it.
Multiple (more than two) key RSA is maybe like this - well i'm not a mathematician, so this algorithm is not necessarily secure, i just want to give an idea with it.
m=p*q*r; p,q,r are big prime numbers
fi(m)=(p-1)(q-1)(r-1)
d==(e1*e2*e3*...*ei)^(-1) (mod fi(m)); e1...ei are arbitrary numbers, d is calculated to fulfill the equation
y1==x^e1 (mod m)
y2==y1^e2 (mod m)
y3==y2^e3 (mod m)
...
x==yi^d (mod m)
This algorithm could be used for example to increase the speed of The Onion Router.