Sorry for my bad English. I have read about Security and understood how RSA work.
But how can RSA keep Authentication, a man in middle can use public key and fake message back. And how it keep Non-repudiation, someone who send you a message encrypted by public key can say that it is not from him and it is faked?
There is some math behind RSA PKI (public key infrastructure) but I will try to keep it simple. Though this scenario is described in many other sites and questions/answers. What exacly you don't understand?
The idea is, that it is easy to encrypt with the public key, but not possible to decrypt. The decryption is possible only with the private key.
Seems your question is aiming somewhere else. What you are missing (and is not part of the RSA itself) are certificates. Certificates may use RSA. A certificate is information about a holder of the public key. Still - there is a problem. If an entity (person, website) provides you a certificate, how can you be sure the cretificate really belongs to the website, person or organization?
That's why there is defined term Certificate Authority (CA) - there are organizations which you (or your browser) should trust.
So when a website creates its RSA keypair, some certificate authority issues a signed certificate (bound to the public key) that the certificate is really from the website, person or organization.
a man in middle can you public key and fake message back.
Your client (browser, application) must have a list of trusted Certificate Authorities. Usually it is already stored in your system. So the real web page can provide its public key and certificate and use encryption based on the public key. The browser checks that the certificate is valid and it is issued by a trusted authority.
The "man in the middle" would not be able to provide valid and trusted (signed by CA) certificate.
And how it keep Non-repudiation, someone who send you a
message encrypted by public key can say that it is not
from him and it is faked?
The same comes to the signing. Once data are signed (or authenticated) using the private key, the signature can be validated by anyone using the public key. A certificate is bound to the public key. Usualy the signing certificate is issued only when identity is verified by the certificate authority (for example for electronic ID cards, code signing certificates, ..). So anyone could verify the signature was created by someone who was verified by a trusted authority.
Related
I'm building an identity service using PKI and MTLS for authentication.
I use AWS ACM PCA for private certificate authority and AWS KMS for key pairs.
I use the private key created by KMS to sign the Certificate Signing Request that's sent to PCA for creating a client certificate.
The client certificate is then bundled together with the CA certificate chain and the private key in PKCS#12 format and returned to the user which is used to authenticate the user.
We also want the user to be able to sign data, e.g. a json string a PDF file e.t.c.
According to KMS documentation they recommend different types of keys for signing and encryption.
So, do I need different certificates for signing data and if so, what's the point of the signing certificate if the data is signed with the private key and the authentication is made with the client certificate?
We want to be able to authenticate the user using one certificate which is not protected by a password and require password for signing, so I guess we need different PKCS#12 stores?
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
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.
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.
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.