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.
Related
So, I'm building an application for MTLS authentication and generate X509 certificates using AWS ACM PCA and bundle them together with a private key in PKCS#12 format.
At the moment I generate key pairs programatically in Java which are never stored.
But since I'm not a security expert I thought maybe it's better to use AWS KMS for creating key pairs.
So, it seem like what I need is a CMK which can generate data key pairs which are stored in KMS.
If they're stored in KMS and I can fetch the private key at any time, how is that more secure than not storing it at all?
Or is the purpose of KMS only to store keys securely?
If you have a use for the encrypted private key that kms.generateDataKeyPair will provide, then it would be of use. It would also be a nice way to ensure that your keys are being generated securely (secure randomness, etc).
It’s important to note, KMS will not store the generated key pair. The idea is that you would store the plaintext public key, and the encrypted private key, and call kms.decrypt to turn the encrypted private key into plaintext whenever you need it.
Provided I have a valid CA issued .cert file. Technically, how many keys a single .cert file can have? more than one public key? or only one public key
As said in comments, an X.509 certificate (RFC5280) contains exactly one public key. No more, no less.
For same subject, will CA issue more than one certificates?
CA may issue as many certificates to same entity as necessary. There are no limitations on the amount of issued certificates per subject.
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.
In case of claim based authentication which uses SSO, an application receives a token from the issuer for a particular user and that token contains the claims as well as some sort of digital signature in order to be traced by the application that an issuer is a trusted one.
I want to know, if there are some sort of algorithms involved by which this application recognizes an issuer?
I had read that issuer has a public key and all the other applications have their own private key, is it true?
There are many protocols, formats and methods of doing Single Sign On such as Security Assertion Markup Language (SAML), OpenID and OAuth. The goal is for one entity, such as a website, to identity and authenticate the user (such as through a user name and password) and other entities, such as other websties, trust the evidence of that authentication through a token. This means users need not remember yet another password and each website maintain their own list of passwords.
This trust is usually enforced through cryptography using a digital signature. Digital signatures are used because it allows the trusting entity to verify token was (1) issued by the authenticating entity only and (2) not tampered with without being able to impersonate (pretend to be) the authenticating entity.
As you say above, this is performed using asymmetric or public key cryptography. Symmetric cryptography, such as the AES or DES algorithms, use a single key to encrypt and decrypt data. Asymmetric cryptography, such as the RSA algorithm, uses two related keys. Data encrypted using one can only be decrypted by the other and vice versa.
One key is usually kept secret, called the private key, and the other is distributed widely, called the public key. In the example above, the authenticating entity has the private key that allows it to encrypt data that anyone with the public key can decrypt.
It would seem to follow that the authenticating entity would just encrypt the user details and use that as the token. However, commonly used asymmetric algorithms like RSA are very slow and encrypting even small amounts of data can take too long.
Therefore, instead of encrypting the user details, the authenticating entity generates a "hash" or "digest" and encrypts that. A hash algorithm converts a piece of data into a small number (the hash) in a very difficult to reverse way. Difference pieces of data also create different hashes. Common hash algorithms include Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) and its derivatives like SHA1, SHA256 and SHA512.
The hash encrypted with the authenticating entity's private key is called a digital signature. When it receives the token, the trusting entity decrypts the token using the authenticating entity's public key and compares it to a hash it calculates itself. If the hashes are the same, the trusting entity knows it has not been modified (because the hashes match) and it must have come from the authenticating entity (because only it knows its private key).
If you want more information about SAML and claims-based authentication, I found this video very helpful. It does get complicated rather quickly and you may need to watch it multiple times but Vittorio covers most of these concepts in great detail.
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.