I quite understand the part that after creating a CSR it is sent to the CA where it is signed with its private key. Now I want to create an algorithm that would do a backward check of authenticity from "pubcert>issuing ca>to subroot ca> to root ca" by verifying the signatures in its certificates and the public key of the CA that signed it. The problem is I don't know what is the input needed to do verification. See to initiate verification i have to do like "C_Verify(session handle, public key, input, inputLength, signature, signature length)". In my case, signature and signature length is from the pubcert while the public key would be from the issuing CA but I do not know what the input part would be?
Related
We have a script that digitally signs a file with a user's private key. The file and signature are then sent to an external server, where the signature is verified with the user's public key.
A sysadmin on our team wants the script to calculate the SHA-512 hash before sending, then have the hash verified on receipt. He says this is necessary to ensure the file isn't modified in transit.
I've replied that digital signing does just that: It calculates the hash of the file, the hash is encrypted with the private key. On receipt the hash is decrypted with the public key. The decrypted hash is compared to a newly calculated hash. If they match, that verifies both that the user's signature is legitimate, and that the file hasn't changed in transit.
I'd like to run this discussion past the Stack Overflow community: If a file is digitally signed and verified, is it necessary to separately calculate the hash before and after signing?
You are correct, signing a file means actually signing the hash of a file. Therefore to verify the signature, it is again necessary to calculate the hash of the file (which is done in place, while verifying). So no need to extra verify the hash.
There is a nice post on the security stackexchange: https://security.stackexchange.com/questions/198423/what-does-signing-a-file-really-mean/198428#198428
Bob uses her public key to verify it [the file] and gets her calculated hash. He then calculates the hash of the file himself (without the signature of course) and checks both hashes. If they match its the same exact version of the file Alice sent. If they don't match Mallory could have changed it.
I have private key (not RSA) and i want to generate JWT using <jwt.io> using RS256. How can I generate a token?
Whenever I enter my private key it says invalid signature. If I need to pass RSA private key then how to convert my private key to RSA private key? I am totally new to this.
RS256 is an asymmetric signature algorithm, that means you need a keypair consisting of private and public key. You can generate such a pair with various online tools or with openssl.
To generate (i.e sign) a token, you need the private key.
But for verification, you need the public key. As long as you only paste the private key into the field in the right column, JWT.io can sign a token, but can't verify it. Therefore paste both keys of the pair into the key fields to get your token signed and verified.
A CSR is mainly created to create a certificate having trusted public key.
Before creating a CSR,
we create a private key
openssl genrsa -out key.pem 1024
and then use that private key(key.pem) to create a CSR(req.pem) request.
openssl req -new -key key.pem -out req.pem
Edit:
I see that a docker engine is installed with root certificate, server certificate & private used with CSR
What is the exact purpose of providing private key(key.pem as input) amidst submitting CSR? Because certificate is supposed to be signed with parent private key
Is private key(key.pem) required to generate corresponding public key amidst CSR creation?
or
Is private key(key.pem) used to encrypt the CSR and the resulting signature is appended to CSR?
The structure of a PKCS#10 certification request (RFC 2986) is, loosely described:
Request:
Info:
Version
Name
PublicKey
Attributes
SignatureAlgorithmIdentifier
Signature
The attributes are attributes for the request, where one if them could be attributes you are requesting for the resulting certificate.
The CA can respect as much, or as little, from the CSR as it chooses. StartSSL, for example, only read out the public key information, and discarded the remainder of the CSR -- everything else they needed was based on your request from their web UI and your account status.
In general, the CA isn't going to ignore the public key value, because if they asserted a new keypair for you they'd need to figure out how you were supposed to get the private key. So, the public key part needs to be present and correct. OpenSSL's command can get the public key value by reading the private key, then it can embed it in the CSR.
The second reason you need the private key is to sign the request. I'll assert that the main reason the request is signed is to force/strongly-suggest you save the private key at this stage, so you don't come back in a few minutes with a "please revoke this new certificate, I already lost the private key" request. The RFC (also) has this to say:
Note 2 - The signature on the certification request prevents an
entity from requesting a certificate with another party's public key.
Such an attack would give the entity the minor ability to pretend to
be the originator of any message signed by the other party. This
attack is significant only if the entity does not know the message
being signed and the signed part of the message does not identify the
signer. The entity would still not be able to decrypt messages
intended for the other party, of course.
I am reading about application code signing in iOS and I don't understand why both private and public key is together? What is the public key and certificate used for when you are signing the application with the private?
Xcode uses your digital identity to sign your application during the
build process. This digital identity consists of a public-private key
pair and a certificate. The private key is used by cryptographic
functions to generate the signature. The certificate is issued by
Apple; it contains the public key and identifies you as the owner of
the key pair.
Let's sum up the process:
You encrypt an hashed digest (like md5 or sha-1) of the executable of application with your private key. That's "signing".
Your users decrypt it with your public key (they have it because it's public) and check it against the executable. As long as your private key stays private, it's you who "signed" it. That's called "verifying".
What about the digital identity then:
You public key isn't public by itself, it must be somehow shared, "made public", and signed by the Certification Autority (hereby CA) too, (that's the CA encrypting it —or an hash of it— with their, one of their, magical mysterious private keys) this guarantees the sharing process hasn't been tampered with by a man in the middle.
So, public key and certificate (CA signature — CA encrypting your public key) identify you (as such are considered part of your "digital identity") and must reach the end user somehow (via a third party, embedded into the executable, you name the way)
The public key is needed so anyone can decrypt the application, and is hence included in the build.
an x509 cert has:
a) the info,
b) the public key,
c) a signed value made from hashing (a)+(b), and then encrypted using the private key
The x509 token profile includes the digestValue and signatureValue elements, shown in this example:
http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfhws/wsSecurity/dfhws_soapmsg_signed.htm
My question is, is the value of signatureValue the same as c)? And is digestValue the hash of a)+b)? If so, why is there a redundancy? Or am I not understanding something? Thanks.
DigestValue and SignatureValue tags are properties of the document, not of the certificate. DigestValue is a value of the digest calculated over the signed nodes, and SignatureValue is the signature of the digest, made using the key, information about which (key) is specified in KeyInfo.
You need to refer to XMLDSig standard for more details.