Here is context:
I am using PGP to encrypt messages in a chat web app. After going through some articles, I get brief idea how PGP works and here is how I am doing it with openPGPJs :
Client(web browser) generate the public/private key-pairs and send public key to server to store it.
Sender use receiver's public key to encrypt data and send it.
Receiver use their own private key to decrypt the message.
As a chat app I need to store all messages and decrypt them when user wants to see old message. decryption of messages need the private key. here the client is web browser which neither can store the private keys for long nor can keep them safe. so I decided to store the private key on web server. Now client(web browser) asks server for the private key whenever decryption of message needed.
Considering PGP an End to End protocol, storing private key on server is vulnerable. my question is:
How PGP encryption works for web based applications where client is not able to keep private key safe and confidential?
Is it Okay to store private key on server?
Is there any better way to do this?
Thanks for any suggestions.
Related
I'm looking for USB token solution for asymmetrical decryption purpose. The server has encrypted sensitive data with periodically rotating data encryption key (DEK), which is stored alongside with the encrypted data, encrypted itself with pre-distributed public key of the USB token (KEK).
The user (web browser client) logins to the single page application with username and password. User then inserts the USB token, which will trigger the following sequence:
Retrieve the encrypted DEK's from the server
Decrypt the DEK's with USB token private key
Retrieve the data from the server with the DEK's
I have looked into solutions like Yubikey, but it seems to be more focused on the user authentication than cipher services. What is the correct product to implement hardware based cipher in portable format? Expensive HSM is out of question, as multiple users should posses an instance of the portable token. Also, each instance should contain the same private key.
Nice idea, however you are having a few issues
Decrypt the DEK's with USB token private key
Currently no browser supports using decrypting by pkcs#11 (smart card or usb token keystore protocol) directly.
The browsers can use a stored keypair to authenticate and that's it. (if I missed something, please correct me).
Though you could use some local utility(non-web) to decrypt using a smartcard (gpg, openssl,...)
Also, each instance should contain the same private key.
Most of the serious smart cards allow generating a new private key, but you not importing own key material (at least the ones I had). So it is difficult to create multiple smart cards with the same keypair
What you could do is encrypt the DEK for a set of public keys
Let's say I have sensitive data in the database server that needs to be encrypted (i.e emails, etc..) and I want to make sure that in the event that the server is compromised, the attacker shouldn't be able to decrypt these data (at the very least make it harder).
I've read some solutions online, and it seems like I can either
Use Hardware Security Modules (i.e. Amazon KMS/Vault) to having a separate server handle encryption/decryption.
Use Public Key Encryption (where the public key in database server encrypts data, and a private key is stored in separate server that solely handles decryption)
What are the tradeoffs of each other and which one would you choose?
If they are tied to just one specific device, when do they change?
If they are device specific, how is that I can check my email on multiple computers or smartphones? If each computer has a different public key and a different private key, how can each successfully decrypt the message?
Sorry if this question is layman.
There are several good explanations online of public key cryptography. This is a pretty good one I recently came across. The key thing to know about public key cryptography (without getting into a huge amount of detail) is that you have two keys: with your public key (which you can share, hence the name), I can encrypt things that can only be opened with your private key. Both you and the server have a public key, thus you can encrypt messages back and forth. This is encryption -- that is, it is entirely to keep the conversation between the server and client secret, and away from prying eyes.
This is entirely separate from the reason that you are able to log into a website from multiple devices! For this, you are typically using a password. That is what is common among all your devices that allows you to log in -- your input.
No, key pairs are not tied to a device.
There are standards for the encoding and storing public and private key information so that a key pair can be exported from one application and imported into many others. Of course, not every application or operating system that might generate key pairs supports these standards or permit this operation, but most do.
Encrypted email is not commonplace, and even today, setting up email encryption is harder than it needs to be. So, if you (or your system administrator) didn't do anything deliberate, like generating a key pair, and purchasing a certificate for your public from a certifying authority, then exporting the key store to your various devices (or the analogous activities for PGP), I doubt you are using "encrypted email."
Most mail servers support "transport encryption", where TLS ("SSL") is used to keep your mail (and mail service password) private. But this is different than encrypted email. Encrypted email using S/MIME or PGP will protect your email while it's stored on servers or on your client, and on any links between mail servers that don't use TLS.
Scenario:
Multiple clients to upload files to server over HTTP/S.
Files are to be encrypted with company public key, for later decryption with company private key on a different environment. On upload, files are dropped (encrypted with company public key) on server.
Going the other way, company has to send documents back to clients. Each document is encrypted using public key of client and posted to the company server for retrieval. Client logs in to server over HTTP/S and grabs encrypted file. Once document is on client machine, they are to decrypt it using their private key.
Questions:
- What is the best way to store the client public keys such that the application can easily grab these at encryption time? If a key server, where should the key server reside?
- Once client has grabbed the encrypted file and downloaded it to their environment, is there an opensource option to decrypt the file?
This is ideally done in a Microsoft environment using ASP.NET. Any additional components, including keyserver are ideally opensource or failing that, affordable to a non-profit.
i want to convert p12 key to pem to use it in a Push notification service for iphone.
i found a website that do that for free (https://www.sslshopper.com/ssl-converter.html)
my question is:
is it safe to use a public website to do this conversation, or it may cause some issue as this website can access my iphone application and send notification for my users?
Your private key is private. By sending the private key to a 3rd party, the 3rd party can identify themselves as you. They won't be able to get a certificate for it without the username and password for the Apple ID that has access to the provisioning portal. But if they in some way get a hold of your certificate, and they already have your private key, they have full control. So in a way it becomes a question of whether or not you trust sslshopper.com to not abuse your private key.
The openssl CLI has all the tools you need to convert keypairs and certs from and to all kinds of formats, in a trusted (1st party) environment.