What is the difference between encrypting and signing in asymmetric encryption?
回答1
When encrypting, you use their public key to write a message and they use their private key to read it.
When signing, you use your private key to write message's signature, and they use your public key to check if it's really yours.
I want to use my private key to generate messages so only I can possibly be the sender.
I want my public key to be used to read the messages and I do not care who reads them
This is signing, it is done with your private key.
I want to be able to encrypt certain information and use it as a product key for my software.
I only care that I am the only one who can generate these.
If you only need to know it to yourself, you don't need to mess with keys to do this. You may just generate random data and keep it in a database.
But if you want people to know that the keys are really yours, you need to generate random data, keep in it a database AND sign it with your key.
I would like to include my public key in my software to decrypt/read the signature of the key.
You'll probably need to purchase a certificate for your public key from a commercial provider like Verisign or Thawte, so that people may check that no one had forged your software and replaced your public key with theirs.
回答2
In RSA crypto, when you generate a key pair, it's completely arbitrary which one you choose to be the public key, and which is the private key. If you encrypt with one, you can decrypt with the other - it works in both directions.
So, it's fairly simple to see how you can encrypt a message with the receiver's public key, so that the receiver can decrypt it with their private key.
A signature is proof that the signer has the private key that matches some public key. To do this, it would be enough to encrypt the message with that sender's private key, and include the encrypted version alongside the plaintext version. To verify the sender, decrypt the encrypted version, and check that it is the same as the plaintext.
Of course, this means that your message is not secret. Anyone can decrypt it, because the public key is well known. But when they do so, they have proved that the creator of the ciphertext has the corresponding private key.
However, this means doubling the size of your transmission - plaintext and ciphertext together (assuming you want people who aren't interested in verifying the signature, to read the message). So instead, typically a signature is created by creating a hash of the plaintext. It's important that fake hashes can't be created, so cryptographic hash algorithms such as SHA-2 are used.
So:
- To generate a signature, make a hash from the plaintext, encrypt it with your private key, include it alongside the plaintext.
- To verify a signature, make a hash from the plaintext, decrypt the signature with the sender's public key, check that both hashes are the same.
回答3
There are two distinct but closely related problems in establishing a secure communication
- Encrypt data so that only authorized persons can decrypt and read it.
- Verify the identity/authentication of sender.
Both of these problems can be elegantly solved using public key cryptography.
I. Encryption and decryption of data
Alice wants to send a message to Bob which no one should be able to read.
- Alice encrypts the message with Bob's public key and sends it over.
- Bob receives the message and decrypts it using his private Key.
Note that if A wants to send a message to B, A needs to use the Public key of B (which is publicly available to anyone) and neither public nor private key of A comes into picture here.
So if you want to send a message to me, you should know and use my public key which I provide to you and only I will be able to decrypt the message since I am the only one who has access to the corresponding private key.
II. Verify the identity of sender (Authentication)
Alice wants to send a message to Bob again. The problem of encrypting the data is solved using the above method.
But what if I am sitting between Alice and Bob, introducing myself as 'Alice' to Bob and sending my own message to Bob instead of forwarding the one sent by Alice. Even though I can not decrypt and read the original message sent by Alice(that requires access to Bob's private key) I am hijacking the entire conversation between them.
Is there a way Bob can confirm that the messages he is receiving are actually sent by Alice?
- Alice signs the message with her private key and sends it over. (In practice, what is signed is a hash of the message, e.g. SHA-256 or SHA-512.)
- Bob receives it and verifies it using Alice's public key. Since Alice's public key successfully verified the message, Bob can conclude that the message has been signed by Alice.
加密和签名的区别
举个例子，就拿A给B发送经过签名加密信息来说：
1、A对信息签名的作用是确认这个信息是A发出的，不是别人发出的；
2、加密是对内容进行机密性保护，主要是保证信息内容不会被其他人获取，只有B可以获取。也就是保证整个过程的端到端的唯一确定性，这个信息是A发出的（不是别人），且是发给B的，只有B才被获得具体内容（别人就算截获信息也不能获得具体内容）。
这只是大概说了作用，具体说来，涉及到密钥相关的东西。密钥有公钥和私钥之分。
那么这里一共有两组四个密钥：
A的公钥（PUB_A），A的私钥（PRI_A）；B的公钥（PUB_B），B的私钥（PRI_B）。
公钥一般用来加密，私钥用来签名。
通常公钥是公开出去的，但是私钥只能自己私密持有。
公钥和私钥唯一对应，用某个公钥签名过得内容只能用对应的私钥才能解签验证；同样用某个私钥加密的内容只能用对应的公钥才能解密。
这时A向B发送信息的整个签名和加密的过程如下：
1、A先用自己的私钥（PRI_A）对信息（一般是信息的摘要）进行签名。
2、A接着使用B的公钥（PUB_B）对信息内容和签名信息进行加密。
这样当B接收到A的信息后，获取信息内容的步骤如下：
1、B用自己的私钥（PRI_B）解密A用B的公钥（PUB_B）加密的内容；
2、得到解密后的明文后用A的公钥（PUB_A）解签A用A自己的私钥（PRI_A）的签名。
从而整个过程就保证了开始说的端到端的唯一确认。
A的签名只有A的公钥才能解签，这样B就能确认这个信息是A发来的。
A的加密只有B的私钥才能解密，这样A就能确认这份信息只能被B读取。
数字签名是什么？ 阮一峰翻译的
http://www.youdzone.com/signature.html
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
数字签名的生成，
首先根据文件内容生成hash，这个hash被称为数字摘要digital digest。然后通过私钥加密这个数字摘要，得到数字签名。
证书中心，是为了验证公钥的可信性。别人提供给你一个公钥，但是中途可能被人替换。
后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。
鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。
苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。
https://www.docusign.com/how-it-works/electronic-signature/digital-signature/digital-signature-faq
What is a digital certificate?
A digital certificate is an electronic document issued by a Certificate Authority (CA). It contains the public key for a digital signature and specifies the identity associated with the key, such as the name of an organization. The certificate is used to confirm that the public key belongs to the specific organization. The CA acts as the guarantor. Digital certificates must be issued by a trusted authority and are only valid for a specified time. They are required in order to create a digital signature.