when we want to encrypt a message by a public key, how we can ensure the public key owner has its private key too?
the rules are:
we do not want to have any information about private key that makes a security issue.
2.the verifying have to be done in a single request and not in a promise.
3.do not use any way that needs to store some data on the key receiver.
the only way that i can see is sending a random message that encrypted by the public key and ask from the key owner the decrypted message to compare them and ensure the public key sender have its private key too; but this way needs a promise like and two steps to verifying and storing some data:
receive a public key and send the encrypted random string and wait
receive the decrypted data and compare them with original string
now do you know any way to do this verifying without need to storing any data
and just do it with a single request may be by some extra data to send by the public key or some thing else?
or is there any other public key encryption algorithm that has this feature built-in?
Using S/MIME as an example, one pre-requisite of encrypting a message to the recipient is to have their Public Certificate.
Now, of course, the recipient can first send you their certificate as an attachment, however, it is more common for the recipient to first send you a signed email.
This signed email would prove that the recipient has access to their private key as they would hash the contents of the email and then sign the hash with their private key.
You would then verify the hash with their public key (the certificate is sent along side the email) and comparing that hash to the hash of the MIME content of the email.
Related
I've generated a key-pair using keytool -genkeypair command. I presume this create a pair of private key and public key.
I've also generated a CSR out of this key-pair using the keytool -certreg command. I got it signed by our CA (or whatever they call it) and I got another certificate in return along with it is its thumbprint.
My question is, what am I going to use that certificate for or what is its purpose? I'm still able to generate a JWT just using the private key.
A key is a set of mathematical parameters describing how to initialize certain algorithms for cryptographic operations, e.g. for signing/verification or for encryption/decryption.
A key pair merely is a pair of such keys where each key can verify what the other one has signed or where each key can decrypt what the other one has encrypted.
One key in such a pair is declared the public key and the other one the private key. (This choice is not completely arbitrary, there can be different extra requirements to a private key than to a public one.)
There is nothing in these keys declaring that they are bound to a specific person, to a specific issuer, to a specific purpose, to a specific accountability, etc.
This is where X.509 certificates come into the picture: A X.509 certificate is a structure that bundles the public key of a key pair with extra information like the name of the holder of the key pair, the name of an issuer of the certificate, validity time spans, and much more.
This structure furthermore contains a signature of all those other data in the structure. This signature is generated using the private key of the issuer of the certificate.
The information in the certificate in particular allows you to determine the issuer of it. If you trust organization of the issuer to only issue certificates to persons whose identity they checked, and if you successfully validated that the certificate signature is valid and created by the issuer, you can trust the identity of the holder of the key pair of a given certificate.
Thus,
My question is, what am I going to use that certificate for or what is its purpose? I'm still able to generate a JWT just using the private key.
you provide your certificate publicly to allow people to be sure of your identity when they use the contained public key to validate your signatures or encrypt information they send to you. Without a mechanism like the certificates you'd have to give people your public key in person for them to be sure of that.
I created private and public key using OpenSSL via the following commands
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
The Question is:
Is creating DKIM key (private and public) using Openssl is safe, Is Openssl the preferred tool to do that.
Can I add the public.key to the domain’s DNS records (TXT).
Can I used private.key to setup DKIM Signing using Nodemailer.
please provide references in your answer
If the answer to above question is no which other tool should I use to do that? please provide the tool's commands that will generate the DKIM key (private and public)
Yes, you can, if your SMTP service allows you to provide an explicit key.
Some mail services require that they generate the key pairs and you only get the public key, they keep the private key stashed to use when signing e-mail. If your service allows you to provide them with the private key, then you are golden.
In fact, Amazon (AWS) requires you to do it this way if you are not using their "easy DKIM" methodology, so I've had to do this myself. Once you have generated those two files, you'll need to securely send the private key to your SMTP service, whatever that entails. Then you'll need to create the TXT record, containing the public portion of the key, for your DNS. It will look something like this:
"v=DKIM1; k=rsa; t=y; "
"n=AmazonSES DKIM public key valid 2020/6-2020/12; "
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRx3I1vkqUygvM4oxOz"
"JUJfdV/QCvpqnOvtL2CuWuSgKcHH7CmVsb9MXGokHDXYRLgMyR8P2GD6peE"
"CdBwBd2vb643rX6saCb7uirI/NcllRsahtfa2Ier6sF8wBhbkWJRmfVhlvT"
"08BYW06MWS5uAkgdg7pFmpwbpTBkeMQMSLwIDAQAB"
The name of the TXT record in your DNS will either be decided by your SMTP service or it will allow you to specify it (called the selector). This is a field that will be placed into the signature header to match that particular e-mail header to the proper TXT record name. The name should have something indicating the version of the key, or the date on which it was generated, since that name will change when you refresh your key. An example would be "June2020.AmazonSES" for the key above. In this case the TXT record name should be:
June2020.AmazonSES._domainkey.example.com
You should never give the private key to multiple SMTP services. Generate a unique key for each, so there will be at least one TXT record per service. This allows you to update just the one if it was hacked without compromising any of the other services you use.
Also, use DMARC to get mail processors who get mail from you to send you error messages (to a mailbox you define in the _dmarc TXT record), so that you can decide when things are working well enough to take it out of test mode.
At the moment I want to implement a method that stores certain data server-side only encrypted. For this procedure is provided that each authorized user receives a private key, with which he can store and read encrypted data. Now it is so that several authorized persons are allowed to look at the same encrypted content. This means that if person A stores data encrypted with his private key, person B (if authorized) can also read this data with his private key.
The idea of implementation:
For all authorized persons, a single symmetric key is generated on the server side. The key is used to encrypt and decrypt plain text data. Now, for each individual claimant, a key pair is generated (public and private). With the public key, the symmetric key is encrypted and stored for the user and there are several of these asymmetrically encrypted symmetric keys on the server. The private key is given to the user (as a file download, HTTPS), which later can be used to decrypt the encrypted symmetric key. Therefore He can upload his private key before writing or reading encrypted data, in a web application (client side) and send it to the server. The Server uses the private Key to encrypt the content of the user and save it, or decrypt older content and send it in plain text to the user.
My problem now is that the weak point is the server, where the private key of the user must first be sent to encrypt and decrypt. There might be someone with access this private key secretly intercept and save.
My question now: Is there an alternative to the approach or does one have to do so if he wants to implement such a procedure? It is important that the data is stored only encrypted. And also this must be implemented with a client web-application and a backend.
Scenario
A SOAP web service provides an interface for retrieving documents and data. Security is paramount.
WS-Security is used and both the client and server encrypt and sign the entire SOAP envelope.
Questions
Should the private key used for signing be compiled into the application and stored on the device or should it provided by the server using a key exchange protocol (perhaps after authentication of the user)?
Should the private key for decryption be stored on the device or provided by the server?
Is it realistic to have a unique key for each file that is to be decrypted by the server (if uploading from client) or decrypted by the client (if downloading from server)?
Just a couple suggestions:
-You should consider symmetric keys embedded into anything outside your server as public due to reverse engineering (i.e. don't bother even encrypting if the key is out in the wild).
-You should use a per-session symmetric key generated by a secure RNG on the client, and transmitted to the server encrypted with the global asymmetric public key. Private keys have a shelf-life.
-You can use the session key for all files/streams transferred in that session, but you should use a unique nonce to salt the symmetric-key encryption for each file. Depending on the encryption mode, using the same key/nonce with more than one stream can leave you vulnerable to XOR'ing the two streams and recovering a mashed-together but unencrypted result.
The entire concept of a private key is defeated if it has to be transmitted from one device to another. Each end of the communication channel must generate their own private keys. Note, that this doesn't mean compiling private keys into an executable, because then everyone with the executable shares a private key, which is obviously not what you want. Each individual device has to use a cryptographically secure source of random numbers to generate it's own public/private key pair. Then public keys can be exchanged in the clear, you can use them to exchange session keys (which can be unique for each and every file), private keys can sign, and everybody is happy.
But remember: Never, ever hard code private keys, and never, ever share them with anybody.
I'm working on a Single Sign On solution to allow my company to integrate with other vendors.
As I'm doing my research, one thing is constantly confusing me.
My understanding of Public/Private key is that data is always encrypted with the vendor's public key and they decrypt using their private key. So far so good.
However, to validate that the message is really coming from me, I will compute the hash of the message and encrypt the hash with my private key (this process is also known as signing). To verify that the message is coming from me, the vendor will use my public key to decrypt the Hash and compare it with the unencrypted hash. If they match, the vendor can be confident that it came from me.
So how come my private key is used to encrypt the message..and how can public key decrypt the message? I thought Asymmetric keys doesn't allow that..! i.e Public Key always encrypts and private key always decrypts. Any explanations will be greatly appreciated..!
Encryption and signature are two different systems. In some ways, they work in opposite directions.
With public-key encryption, anybody can encrypt data with the public key. Only the owner of the private key can decrypt encrypted messages to recover the data.
With signatures, only the owner of the private key can sign messages. Anybody can use the public key to verify the signature of a message.
My understanding of Public/Private key is that data is always encrypted with the vendor's public key and they decrypt using their private key.
That's correct. But it only covers public-key encryption, not other uses of public-key cryptography such as signatures.
However, to validate that the message is really coming from me, I will compute the hash of the message and encrypt the hash with my private key (this process is also known as signing).
Actually, this process should only be known as signing. Calling it “encrypting with my private key” is very misleading: that's not the way it actually works. There is one popular type of keys (RSA) which can be used for both signature and encryption, but even with RSA, the signature and decryption mechanisms are different.
To verify that the message is coming from me, the vendor will use my public key to decrypt the Hash and compare it with the unencrypted hash. If they match, the vendor can be confident that it came from me.
That's not quite correct. Many signature algorithms are not deterministic. Verifying a signature is not done by reversing the signature process, but by making some slightly different calculations involving the signature, the message and the key.
So how come my private key is used to encrypt the message..and how can public key decrypt the message? I thought Asymmetric keys doesn't allow that..! i.e Public Key always encrypts and private key always decrypts. Any explanations will be greatly appreciated..!
The private key is used to sign the message, not to encrypt it. The public key is used to verify the signed message, not to decrypt it.
i found this link very helpful :
http://www.nusphere.com/products/library/ssl.htm
Wayback Machine archive from 2007 of the above nusphere link.
HTH
Ohad
EDIT
after 2.5 years, I see that the link is broken. So this one is good as well.
And in case it will be broken again in 2.5 years from today, here is the summary:
The Public Key is what its name suggests - Public. It is made
available to everyone via a publicly accessible repository or
directory. On the other hand, the Private Key must remain confidential
to its respective owner.
Because the key pair is mathematically related, whatever is encrypted
with a Public Key may only be decrypted by its corresponding Private
Key and vice versa.
Public Key Cryptography can therefore achieve Confidentiality. However
another important aspect of Public Key Cryptography is its ability to
create a Digital Signature.
The difference between symmetric and asymmetric encryption is only the existence of private and public keys.
Nevertheless in the common algorithms you can use the private key to encrypt messages which can be decrypted with the public key and you can also decrypt messages which are encrypted with the public key. So it is possible in both directions.