I am working on a system where I need to store an RSA private key on a server.
I intend to use OpenSSL to generate the private key and to apply a passphrase to it so that the private key is encrypted on the server.
Can anyone tell me what process OpenSSL uses to encrypt the private key? In other words, how does it use the passphrase to generate an encrypted version of the private key?
I believe that TripleDES is used here somehow to symmetrically encrypt the private key. Is there a salt added to the passphrase, or can a salt be added somehow to make it more secure?
Any advice that you can give would be much appreciated.
Related
I'm trying to implement OpenPGP end to end encryption on a simple messaging app which will be accessed on the web as well as mobile. I'm stuck at deciding where my private key should be generated and stored. The following two approaches are on the table(i don't want to go with approach 2 but that looks like the only feasible option) :-
Key storage approach 1:-
When the user logs into the Chat client the first time, the client (web/app) will generate a set of public and private keys.
The user's public key will be sent to the backend server. The user's private key will be encrypted and stored on the local storage of the client.
Problems with this approach:-
If the user has not logged into the client even once, how will the sender encrypt the message? (since the public key of the recipient is not available till now)
If the user logs into another client (another browser or different app), how will he get access to the private key? (since that is needed to decrypt the messages in the user's inbox)
Key storage approach 2:-
When the user is created on the backend server, create both public and private keys for the user using PGP on the backend itself. Public key can be stored in plain-text but the user's private key should be encrypted and stored. We can use symmetric encryption with a client-specific passphrase here.
When the user logs into the Chat client (web/app), the encrypted private key will be received from the backend upon login. In order to decrypt any message, then can decrypt their private key using their passphrase, then use the private key to decrypt the message received.
Problems with this approach:-
This is not truly end to end encryption, since who-ever knows the passphrase of the user, can have access to the private key.
Reg. approach 1: If the client hasn't had the opportunity to share their public key, then indeed, you cannot send encrypted messages. It's unclear how you would solve that problem. The private key you can encrypt with a passphrase and upload the encrypted version to your backend so that the client can then download it and have it available on other devices, as you write in your second approach. Or you can go a step further and generate the private from the passphrase.
Your approach 2 may actually not have much worse security properties, depending on how you look at it. You could argue that you have no infrastructure anyway to let clients make sure they have obtained the correct key material. So they cannot distinguish the actual public key of the user from a malicious one provided by the server.
How you design your system is up to you, of course. I suggest you start laying out your requirements. Your problems seems to become smaller if not-yet-known users do not need to receive encrypted messages.
I have to store sensitive data on the server for a web application. The data has to be viewable in plain text later so I can't hash it.
My question is what would be the most secure way to apply the algorithm / where to store my key. I could store it locally on the server or do you have any ideas to store this data as secure as possible while still being able to decrypt it?
We cannot decrypt a cipher text without a key. Hashing is an irreversible process. It wont work in your scenario. There are two types of cryptography techniques: Symmetric and Asymmetric.
Asymmetric cryptography is maintaining two keys for everyone:public key and private key.When you want to communicate with someone, you should encrypt the plain text using their public key and they will decrypt the same using their private key. When they want to communicate with you, they will encrypt the plain text using your public key and you can decrypt the same using your private key. So every party should hold two types of keys.
Symmetric Cryptography is maintaining a single key for a communication. The single key will encrypt and decrypt the data. When two parties wants to communicate, they should have a shared secret key (common key). When you want to communicate, you can encrypt the plain text using the key and they will convert back the cipher into plain text using the same key.
In your scenario, you can use Symmetric cryptography techniques such as AES,DES etc., You can maintain a separate key for every user. You can use that key for encryption and decryption. The keys can be stored in another database. whenever you want to display the password in plain text, you can take the key for the user and decrypt it using the same cryptographic technique.
I am using a local URL scheme to submit a payload to the client when a user clicks a link and have to make sure that this is only used in my specific web application.
So I am using a key pair, encrypting the payload on the server using the private key, generating a link that the protocol handler on the client can decrypt using the public key, verifying that the payload should be processed.
So is it less secure to send a private-key-encrypted payload instead of a cleartext payload plus signature (and if yes, why)?
Found out that there are other Stack Exchange sites that answer this question very well:
https://crypto.stackexchange.com/questions/2123/rsa-encryption-with-private-key-and-decryption-with-a-public-key
https://security.stackexchange.com/questions/11879/is-encrypting-data-with-a-private-key-dangerous
I should have searched a little bit longer before asking.
What you are doing is signing!
Encrypting is when a payload is being concealed with one’s public key and later decrypted with a private key. When I want to send you a secret message, I will take your public key (because I know it) and encrypt my message. This will make sure that only you can decrypt it with your private key.
Signing works vice versa. If during encryption I want to make sure that only you can decrypt me message, with signing I want to make sure that all recipients of the message can be sure in its authenticity. If you encrypt something with your private (signing), anyone with your public key can decrypt it and verify its sender.
In your case, if you just want to prove your identity (like certificates, jwt tokens, etc.), you would need to use signing methods. If you want to transfer payload securely, use encryption.
Hope this helps!
So I'm developing my messanging app with encryption evolved using RSA. Currently I came up with this algorithm:
= Update for auth =
Screenshot:
In this case private keys are generated only from password, and server knows only password hash just to authorize users (unhashed password is never transmitted to server), therefore is unable to generate private keys or decrypt any old message. If server will fake a public key recipent will be unable to verify signature encrypted with sender's private key.
The problem is that server can fake a sender's private, public key and password when he signs up on a service or requests a password change and recipent will be unable to detect it. So, how can I verify that keys were not faked by the server?
So, how can I verify that keys were not faked by the server?
You cannot. So long as the clients only communicate with the server, there's no way for them to distinguish between a "real" remote user and one that's being MITMed or otherwise faked by the server.
I see a couple other serious potential issues here:
Sending an unsalted hash of a password over the wire (during the login process) is hardly better than sending the password in the clear. An attacker can sniff the hash off the wire to log in -- they don't need the actual password! -- and a non-iterated SHA256 is highly vulnerable to brute force attacks.
"private key from pass" (also in the login process) implies that you're using some sort of KDF to generate a private key from the user's password. This has multiple negative implications:
Users are generally pretty bad at choosing passwords. This implies that the private keys will also be weak.
If two users happen to use the same password, they will end up with the same private key.
Any user can attack the password (and hence the private key) of any other user that they've communicated with by running the KDF on candidate passwords.
There is no process specified for negotiating a symmetric encryption key. Using RSA to encrypt messages directly limits each message to the size of the key, and makes it vulnerable to numerous attacks if the data being encrypted is not both random and unique.
In the message exchange, the user sends the server two copies of every message -- one encrypted to the target user's private key, one encrypted to their own private key. In some situations, this may make it possible to recover the message.
My application requires certain fields to be encrypted when stored at rest, and allow the user to decrypt them locally in the browser by entering a passphrase. However, these encrypted fields are not entered into the database by the authenticated user himself, but submissions from other people who are supplying the user with private information.
If I stored the passphrase in the database to encrypt new submissions, then anyone who got access to the database would be able to easily decrypt the encrypted information. So, I believe I need to store a public key in the database, encrypt incoming information with the public key, and then serve that encrypted info to the user and let him decrypt it with his passphrase in his browser. (Thus, serverside, we can never decrypt anything.)
I've looked into libraries like ursa, but the problem is that the user would have to save his private key. (Correct?) Is there any way that I can do this with a relatively short passphrase instead of a long private key?
You can use something like JSBN to generate a public-private key pair on the client and use CryptoJS in password encryption mode to encrypt the private key with AES. The encrypted private key and the plaintext public key are then posted to the server and added into the database.
The next time the user gets information encrypted with his/her public key, you send the encrypted information and the encrypted private key to the client/browser. The user can enter the passphrase again to decrypt the private key and then in a second phase decrypt the payload.
Note that this is not absolutely secure because unencrypted traffic (e.g. no TLS) will enable an attacker to extend the html/js to include a data stealing script. Furthermore, the developers of your system can also add such a script whenever they want regardless of TLS or not.