Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
and what are the differences between conventional cryptography and public-key cryptography?
You should probably re-phrase your question:
Public-key cryptography uses an asymmetric approach where the key used to encrypt and the key used to decrypt a message are not the same. Here is a description of the RSA asymmetric algorithm: RSA (asymmetric cryptography)
There is probably no "conventional crypthography". What you probably mean are symmetric algorithms where both keys are the same. Symmetric key algorithm
Basically, public-key cryptography means that you have a "public/private" pair of keys. The public key can be used to encrypt messages, but not decrypt them. The private key is, as the name suggests, secret, and can be used to decrypt the messages.
Typical usage goes like this:
Alice creates a public/private key pair.
Alice sends her public key to Bob, keeping the private key in a safe location.
Bob sends the encrypted message to Alice.
Alice receives the message and uses her private key to decrypt it.
Usage examples of asymmetric encryption:
In situations where no trusted channel can be established for exchanging symmetric keys (e.g. HTTPS): because the public key cannot decrypt, it is safe to send it over an untrusted connection
When the same public key needs to be used by more than one user (e.g. encrypted e-mail): even though all the senders use the same public key, they cannot use it to decrypt any messages; only the recipient has the private key
Related
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).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
Update: reading itext whitepaper on using smart cards to sign and have the following question:
Digital signatures in a smart card: Why have two certificates, one for authentication and the other for non-repudiation? Why can't one certificate be used for both since both authentication and non-repudiation certificates uses private keys to encrypt and public key to decrypt. Is it because the "authentication certificate" contains sensitive info?
It's said that the authentication signatures allows the card to prove his identity and also the certificate contains privacy-sensitive information such as gender, date of birth, and national number. The non-repudiation signature is used for to generate electronic signatures.
It is common practice to have multiple keys for multiple purposes.
There may be a lot of technical differences and procedural differences:
Authentication could have the PIN cached while the private key of the non-repudiation (non-rep) certificate could require a PIN to be supplied by the holder for each signature operation.
One private key could be revoked (e.g. the more sensitive non-rep key) while the authentication key could still be be used.
Authentication maybe used for longer than the non-rep key.
The key usage of the non-rep key could be more strict.
The CA keys of the non-rep key could also have a higher grade of protection.
It used to be the case that e.g. SSL authentication required different signature (MD5 + SHA-1) or encryption operations. The higher the access to keys, the less secure they will be. Nowadays TLS can be used to have a more regular signature in combination with ephemeral Diffie-Hellman.
As Eugene has commented, there may be legislature in place that requires separate keys and/or certificate chains for authentication and non-rep.
Even if all the above are not true yet, they may apply in the future. Hence the specific keys for a specific purpose. And note that the above is just out of the top of my head.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
If want to give someone access to a server via ssh should I create the pair and send them the private key or should I have them create the pair and send me the public key?
The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key, but anybody who has your public key can verify that a particular signature is genuine. That is how server authentication protocols are currently implemented. The server sends a snippet of random data that your client then signs and returns to the server. The server uses your public key to verify the signature.
Note that if the server side has no independent means of knowing that your public key comes from you, then you could use a digital cert signed by a trusted third party to validate the pubic key. Most sys admins don't go this far when setting up authenticated logins manually, but a personal cert is sometimes required for financial systems. Search "PKI".
If the server side generates the key pair, then you would need a way to securely transmit that key pair to an authenticated client, then destroy the private key on the server side.
I would be possible to set up a client authentication system with the private key on the server side and the public key on the client side. The authentication protocol would be that the server would send a random snippet to the client for encryption and the client would return the encrypted snippet to the server. The client would have to secure the public key against compromise, and it would only be good for one server, whereas when the private key is on the client side the client can use the same public key for authentication against multiple servers.
Definitively the second, they should generate the private key and send you the public one, that way you don't send the private key over the wire.
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.
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.