How do the Public key fingerprint and Digital Signature differs ? Or both are same ?
if they are different, what is the application of public key fingerprint ?
Thanks
a public key fingerprint is a short sequence of bytes used to authenticate or look up a longer public key. Fingerprints are created by applying a cryptographic hash function to a public key. Since fingerprints are shorter than the keys they refer to, they can be used to simplify certain key management tasks
A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit. Digital signatures are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery or tampering
A public key fingerprint is a short version of a public key which is used to authenticate a longer public key, if they do not match that means that the longer public key has been tampered with. So basically a digital signature is something that is signed by a user which only that user can sign so you can be sure that it is coming from that user.
So a public key fingerprint is used by a client and the digital signature is used by the server
The fingerprint is the hash of a key. A digital signature is tied to some message, and is typically a one-way encrypted hash of the message.
The two serve different purposes: You can put the public key fingerprint on your card or, if you recognize the other person on the phone, use it to verify you got the right public key(s). It doesn't say anything by itself. The digital signature, on the other hand, says that the message was signed with that key over there, and you don't need any other channel for verification of that fact.
Related
My private key is server-side and the public one are client-side. I use them to sign JWT from my server and sent to my clients, for authorisation. I have now to also encrypt the user password client-side during the authentication using JWE and verify it from server-side.
This two use case have the same requirements: private key is server-side, public key are client-side, and encryption algorithms can be the same. This is why I am thinking to use the same key pair but I am afraid to miss something about security and I would like to have confirmation, is it safe?
As best practice, you should not re-use the same key pair for different purposes. Just have two distinct key pairs, one for digital signatures, the other for public key encryption.
I had a random question while trying to understand digital certificate.
From what I understand, a web server sends a CSR to a CA, which contains web server’s RSA public key and identity (subject, CN etc.). CA adds some more information (e.g. issuer, validity dates), signs this CSR with the RSA private key of CA and thus prepares a digital certificate.
More simply, this is what follows -
Create the certificate content (Client’s public key, Subject, Issuer, Validity dates etc.)
Creating HASH of the above certificate content (fingerprint)
Create signature by encrypting only the HASH (not the entire certificate content) and append this signature to the above certificate content and thus prepare a digital certificate.
(kind of like this one - Digital certificate creation
Am I correct in understanding the creation process of a digital certificate?
If that’s so,
the certificate contents (except signature part) seems totally un-encrypted and thereby can be read by anybody between a client and web server. Thus every device between client and webserver should be able to read the fingerprint and signature. Now that –
Fingerprint of certificate (HASH) + CA’s private key = encrypted text (Signature)
Is there a possibility that somebody can take lots and lots of packet trace of certificates transferred, calculate the fingerprint himself for each certs, create a lot of pairs of fingerprints and signature pairs and find out the CA’s private key by some sort of reverse calculation?
Thanks ..
This is not about programming (and I agree to delete this if necessary to close or delete)
Digital signature is NOT "encrypting with the private key". This is a wrong idea that was popular about 40 years ago, but still lingers because people keep copying it. See my https://security.stackexchange.com/questions/159282/can-openssl-decrypt-the-encrypted-signature-in-an-amazon-alexa-request- .
Web servers, and other SSL/TLS servers, and CAs also, are not limited to RSA. Several other signing algorithms are possible, and currently ECDSA is becoming fairly common. It is fairly common for CAs to use the same algorithm for the cert as the subject's key, i.e. to sign a cert containing an RSA key with an RSA key or one containing an ECDSA key with an ECDSA key, but this is not technically necessary (and 1.3 supports separate negotiations for the server or client sigalgs and the certificate sigalgs, which earlier protocols did not).
The fingerprint of a cert, by convention, is the hash of the whole cert including the signature, not the hash of the signed part which is used in the digital signature computation.
But yes, certificates are designed to be public and can be read by anybody. (For TLS 1.3 the certificate transmission is encrypted so a totally passive eavesdropper can't read it, but a minimally active attacker can simply do their own connection and get the cert(s).) Even the signature can be verified by anybody. For RSA only, verifying the signature involves recovering (not decrypting) and comparing the hash, but even without that anyone can compute the hash of the signed part.
For any signature scheme to be considered acceptable in the past 50 years or so, knowing signatures for valid data, even attacker-chosen data, must not allow either recovering the key nor forging a signature for different data (that the attacker wants) which would be just as bad for security. RSA as currently used as acceptable, although one scheme (block type 0) in early PKCS1v1 last century was not. ECDSA is acceptable if appropriately random 'k' values are used, or instead deterministic but key-dependent ones (see RFC6979 and a dozens of Qs on crypto.SX and security.SX where this is ontopic). However, if two ECDSA signatures are known (for known data) using the same key and k the private key can be recovered; there are also numerous existing Qs on this, including on bitcoin.SX because it occurred on some Bitcoin implementations (look for either "same/duplicate k" or "same/duplicate r" because one component of the ECDSA signature, r, is computed directly from the scalar multiplication kG).
I have started learning GPG and I am a bit confused about the infos I have found. The GnuPG documentation says that
A signature is created using the private key of the signer
But at the Apache's site, they say:
The signature file is a digest of the original file signed by a public key...
And on the same site, in another section, they say the following:
A digital signature is created from an original document using a private key.
Now I suppose that the process of signing involves signing the hash of a release using the private key of the holder and not the public one like Apache says in the second link I have posted, or am I wrong? Otherwise, how could someone be ever able to decrypt the hash of a release signed with a public key if he/she doesn't have the private key of the holder?
Then, could someone simply explain in what the processes of signing and verifying a signature consist and what are the passages, e.g. for a software release like Apache Maven?
TL;DR: There is a mistake in the documentation, your understanding of signatures is right.
The signature file is a digest of the original file signed by a public [sic, this is should be private] key...
Signing a document usually is performed by calculating the hash sum of the document (asymmetric cryptography is very slow for large amounts of data), which finally is encrypted using the private key, so anybody can decrypt it using the public key. If the decryption process results in the same hash sum as is calculated from the original document, it must have been encrypted using the private key - which is only known to the signer; thus the authorship is verified.
Encryption (leaving apart the aspect of hybrid cryptosystems like OpenPGP is, but the general concept stays the same) works the other way round; the public key is used for encryption, so only the private key can be used to decrypt the information.
I added a bug report for the documentation issue (closed/fixed since 2015-07-29).
Then, could someone simply explain in what the processes of signing and verifying a signature consist and what are the passages?, e.g. for a software release like Apache Maven -> https://maven.apache.org/download.cgi?Preferred=ftp://apache.mirrors.tds.net/pub/apache.org/ ?
You need to fetch the public key used for signing the software (usually, you will download it from a keyserver using gpg --recv-key [key-id].
Verify the key's integrity, for example by speaking with the developers, your web of trust, the products HTTPs-encrypted website (depending on how paranoid you're at verifying the authorship).
Issue a signature to certify the key if it is not already verified through your web of trust, if you don't want to create a public one, there are also local signatures which are never transmitted to the key server network.
Finally, use gpg --verify to check that the signature was indeed issued by the product maintainer's key.
My question is: Does the public key in a asymmetric key have to be used to encrypt data or can it go either way (be used to decrypt)?
In RSA the public and private key technically fulfill the same role, one can decrypt what the other encrypted. The only difference is that one is made available to all parties.
Public keys can only be used to encrypt data, and private keys can only be used to decrypt data.
If you could decrypt data using a public key, that defeats the purpose of encryption.
Imagine you put your public key on your Facebook profile so that people can encrypt emails to you if they wish. If public keys could decrypt, then anyone that viewed your profile would have the key to all your emails (that were encrypted using that key pair).
This question already has answers here:
Whose key is used to encrypt a HTTPS response?
(3 answers)
Closed 4 years ago.
What I understand about RSA is that Alice can create a public and a private key combination, and then send the public key over to Bob. And then afterward Bob can encrypt something using the public key and Alice will use the public and private key combo to decrypt it.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
Basically, the procedure is:
The client connects to the server and asks for the server's certificate. The certificate contains the public key and information about the server's identity.
Assuming the client is happy with the server's identity, it generates a random number P and encrypts it with the server's public key.
Only the server can decrypt P (with it's private key - not shared with anybody) so when the client sends the encrypted random number to the server, the server decrypts it.
The client and server both use P to generate a symmetric key for use in a symmetric encryption algorithm, safe in the knowledge that only the client and server know the value of P used to generate the key.
Alice will use the public and private key combo to decrypt it
Alice would just decrypt it with her private key.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it?
Alice would need Bob's public key to send something to him.
Typically, public key encryption is used for authentication, non-repudiation (like signing), and distribution of symmetric keys (which are faster for encrypting/ decrypting long messages).
Simple, you need a key.
SSL/TLS solves this problem by creating a symmetric session key during the connection setup. The public key cryptography is used to establish this session key, which is then used for bi-directional data communication. Read more about TLS
I didn't create this, but someone shared this video with me and it helped the theory make much more sense. As always the devil's in the details (implementation).
http://www.youtube.com/watch?v=YEBfamv-_do
On a general note I struggled to understand Public Key Cryptography for quite a while along with the other elements of PKI such as Digital Signatures and Certificates whilst preparing for Microsoft C# certification.
I came across an explanation in the form of a concise and detailed PDF at cgi.com. I know it's back to good old Alice and Bob! but it really cleared things up for me with its diagrams and notes and also has some thought provoking questions at the end. Definitely recommend it.
Visit http://www.cgi.com/files/white-papers/cgi_whpr_35_pki_e.pdf
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
This is where you're wrong; you do have a private key. As part of the handshaking process, each side generates two keys: a public key and a private key. The client sends its public key to the server, who will use it to encrypt all data sent to the client. Likewise, the server generates both keys and sends its public key to the client, which will use it to encrypt all data sent to the server.
In many scenarios, the asymmetric key algorithm is used only to exchange another key, which is for a symmetric algorithm.
In this situation, Alice would use Bob's public key to encrypt the data and Bob would then decrypt it with his private key.
Essentially, a public key encrypts data and a private key decrypts that data. Since every user has both a public and private key, you can securely send data to any other user.
If you connect to the site of your bank it works a lot of cryptographic things. The most important is that you use public key of the bank to send a piece of information to the bank, because in every SSL (https) connection server send to client it's public key packed as a certificate.
Usage of certificate and world wide PKI is important. You want be sure, that if you gives to the bank your bank pin, that on the other side is really your bank and not an other person. This will be solved, because on every computers there are a small number of public keys of well known organisations (like VeriSign) and bank send you not only his server public key, but a certificate. certificate is a message signed by VeriSign for example, which say "this public key is really from the bank XYZ". So because you have public key of VeriSign you can first verify, that server certificate of the bank is correct. So you can be sure, that you communicate really with your bank.