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.
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 use the mentions software stack above and I need to encrypt password before save into database. I also need to decrypt password because when someone will change password he she needs to give in the old password and then the new onw twice and I need to check the old password.
I have searched a lot but I still not sure what is the right way to do this.
I have found this link Encrypting but are there other hints to do this?
I also not sure if maybe MongoDB provides something to protect passwords.
First read Steven Carlson´s answer about password hashing.
The good thing is that Spring Security will do this for you. Spring Security 3.2 introduced the new org.springframework.security.crypto.password.PasswordEncoder interface and some implementations: BCryptPasswordEncoder, StandardPasswordEncoder (and NoOpPasswordEncoder).
Important: Do not confuse org.springframework.security.crypto.password.PasswordEncoder with the old deprecated org.springframework.security.authentication.encoding.PasswordEncoder
The interface (and therefore the implementations) has the two methods you need:
public String encode(CharSequence rawPassword)
public boolean matches(CharSequence rawPassword, String encodedPassword)
I recommend to use org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder.
The BCryptPasswordEncoder (in contrast to the StandardPasswordEncoder) use an salt that is different for each password (but not global like the one from StandardPasswordEncoder). When you encode a raw password (public String encode(CharSequence rawPassword)) then the returned encoded password is not just the encoded password, it also contains some meta information about the used hash-algorithm, the used salt and of course the encoded password.
You should not be "encrypting" the password at all. I know this sounds counter-intuitive. But there is zero reason your system should need to decrypt the password. To do so would open your database to a hacker, because if you store your decryption password in your codes/server a hacker can steal that information.
The correct process is to hash the password. A hash is a one-way (cannot be decypted back to the original text) process. The current standard would be to use SHA256 to hash your password. Here is a basic flow-chart:
Take user submitted password. Example password "mypass" would hash out to ea71c25a7a602246b4c39824b855678894a96f43bb9b71319c39700a1e045222
Store this hash (ea71c25a7a602246b4c39824b855678894a96f43bb9b71319c39700a1e045222) in your database.
When a user logs in you take the password he just submitted and hash it. If he enters the same password it will hash out to the same value in your database.
When a user goes to change passwords you hash the "enter your old password" to verify the old password still matches, if it does you hash the "enter your new password" and save it.
One thing I did not mention in my example is salt. This is something you must use in your system as it protects your data from rainbow table exploits. But that is for another discussion.
Hope this helps :)
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
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.