Consider the following scenario:
1. I generate a key pair.
2. I then distribute public key to my customer.
3. The customer uses the public key to encrypt a file and then send me the file.
4. I need to identify who the customer is.
I am wondering whether it is possible to extract public key from a gpg encrypted file?
You have this the wrong way around: you can't identify a customer using your public key.
If you want to verify a sender then the message is encrypted using the senders private key which serves as the senders digital signature. The digitally "signed" and encrypted message is then sent to the receiver who can then use the senders public key to decrypt the message and reveal the original contents. This is termed Inverse Public Key Encryption
Also see: Should we sign-then-encrypt, or encrypt-then-sign?
Ref: Public-key cryptography
To answer the title:
gpg --pinentry-mode cancel --list-packets file.gpg
will give you the key-id from the encrypting key,
but will not reveal from, but to whom the file was encrypted.
In this case yourself.
credit to: https://superuser.com/questions/1409511/how-to-check-if-a-gpg-encrypted-file-is-encrypted-using-a-specific-public-key
Related
We're using the Gem: https://github.com/attr-encrypted/attr_encrypted as a way to encrypt some of our fields in our Rails application database.
Because we don't want the data to be accessible (even to developers) who don't know the key we have looked into using the Gem to do proper asymmetric encryption whereby the key is with the user itself and would require their password in order to decrypt certain fields.
For example:
attr_encrypted :example_field, key: proc { |user| user.key }
However I have two questions:
1.) How would we make sure the key itself had to be decrypted on user login? As the current implementation just means we have only made a key per user and moved it into the database and instead of an environment variable.
2.) According to the rules of asymmetric encryption we'd use a public key to encrypt the data and then the private (user key) to decrypt the data... but haven't been able to see how this Gem would support this as seems to only care about a single key for an attribute rather than proper public/private keys.
I'm looking through libsodium-examples of public-key-cryptography and it seems the senders private key is used in addition to the receivers public key when encrypting the plaintext.
Extract from the relevant example:
The crypto_box_easy() function encrypts a message m whose length is
mlen bytes, with a recipient's public key pk, a sender's secret key sk
and a nonce n.
What is the point of this? My understanding was that the senders private key only was used when signing a message?
Digital signatures encrypt with the private key and are decrypted with the public key. This allows anyone to verify the signature with the signer's public key.
The libsodium documentation refers to an "authentication tag" which is explained in a different chapter in the following section:
This operation:
* Encrypts a message with a key and a nonce to keep it confidential.
* Computes an authentication tag. This tag is used to make sure that
the message hasn't been tampered with before decrypting it.
So what libsodium calls authentication tag is equivalent to the more common terminology of signing a message. Therefore it makes sense for the crypto_box_easy(...) function to take the senders private key as input since the encryption really is encryption and signing.
I want to connect two ruby interfaces. I want to pass key and secret from interface 1 to interface 2 in encrypted form and user in interface 2 can decrypt the key and secret if he has a specific password. Which is the best way to implement it?
Use PBKDF2 to generate a key from a salt and the password. You can use this key to perform key wrapping (encryption) over a randomized key you want to agree on. You could simply use AES in ECB mode of operation if you only encrypt a randomized key value.
If you also need to encrypt a message then take the key and use an authenticated mode of encryption like GCM and use that to encrypt. If that's not available then use CBC and HMAC, but don't forget to include the IV vector in the HMAC calculation over the ciphertext. Sending non-authenticated ciphertext over the internet is not likely to be secure.
If available you could also use TLS with PSK authentication. That would almost certainly provide better protection than some kind of proprietary scheme such as the one above.
There are lot of Options available, I liked Gibberish
Gibberish
gpgme
encrypted strings
I have a key pair and I use private key to encrypt the data, public key for decryption. Is it possible to provide confidentiality in this setup ?
No, it's not. You must encrypt data using recipient's public key to have confidentiality. Now all you have are integrity and authenticity (you've got a variation of digital signature, actually)
In the setup that you're asking about, anyone who had access to the recipient's public key (which could be a lot of people if it's truly public) could then decrypt the message, so no, there is no real confidentiality.
If you want to provide both authenticity and confidentiality, you might try encrypting the data with the recipient's public key in order to provide confidentiality, then encrypting (or signing) that with your private key. The recipient would then decrypt (or verify) that data by decrypting it with your public key, thus indicating that the data really came from you, and then decrypting that data using their private key thus helping to ensure confidentiality.
reCAPTCHA requires a public and a private key before it can be implemented into a website. It also needs the reCAPTCHA keys depending on the website. What's the reason behind this? Does the Public and Private key affect the words displayed in the reCAPTCHA? I know that I can set the Public and Private key to be GLOBAL in which it can be used for other domains but why even need the keys in the first place?
OK. This is my guess, no guarantee.
Your public key is required while generating client-side page.
The client uses this public key to request from recaptcha: an image, a corresponding correct answer and perhaps an id. Of course the answer and the id comes encrypted, using the public key. (So the client cannot know the answer)
User types in the answer, sends it to your server.
You have: {id, answer} encrypted using public key. You send your private key and this encrypted message to recaptcha server.
recaptcha unencrypts the message, revealing the answer and id, and checks if they match.
it tells your server the result of the check.
Note:
If the user sends a public key of his own to recaptcha, the check won't succeed since your private key does not work with his public key.
The scheme proves that your server is really the one receiving the recaptcha answer.