公钥私钥（rsa公钥和私钥）

公钥、私钥、密码、助记词、Keystore是在运用数字货币钱包时，必需求弄清的概念：假定不搞清楚,很可以会形成数字资产的严酷丧失。

1.公钥：

相当于所属钱包的地址，可了解成银行账户。

公钥的地址可了解成银行卡号，是由公钥经过计算得来，就像银行先给你开户，后给你银行卡卡号。

钱包地址的主要用途是收款，也可以作为转账的凭证，就像他人汇款给你时你需哀通知他银行卡卡号一样。

稀有的钱包地址样式:

比特币:一般地址:1扫尾、隔离见证地址：3扫尾

以太坊地址：0x扫尾：（包括基于以太坊平台代币）瑞波币地址：r开头。

莱特币地址：L开头。

2.私钥：

十分主要，相当于银行卡号+银行卡密码。

创立钱包后，输入密码即可导出私钥。私钥是由字母数字组成的字符串，一个钱包地址只需一个私钥且不能矫正。私钥要离线保管,不要中止网络传输，可用纸张记载并保管。

主要用途，导入钱包。有了私钥就可以在同系列的任何一款钱包上，输入私钥并设置一个新的密码就可以把之前的A钱包的资产导入B钱包。比如手机丢了，只需你有私钥就可以恢复。

3.密码 ：

相当于银行卡密码。

在创立数字货币钱包时，需求设置一个密码，一般央求不少于8个字符。

主要用处：①转账时需求输入密码，可理解成你用银行卡给他人转账需要输入密码；②用Keystore导入钱包时，必需输入这个密码。

密码可以中止矫正或重置。输入原密码后，就可以直接矫正新的密码了；但假定原密码遗忘，可以用私钥或是助记词导入钱包，同时设置新的密码。数字货币钱包中，一个钱包在不同手机上可以用不同的密码，相互相互独立，互不影响。

4.助记词

等于私钥=银行卡号+银行卡密码

由于私钥由64位字符串组成，便利于记载，十分冗杂抄错，于是就出现了助记词,便应用户回想和记载。由12个单词组成，每个单词之间有一个空格，助记词和私钥具有十分的功用：只需输入助记词并设置一个新的密码，就可以导入钱包。

一个钱包只需一套助记词且不能修正。助记词只能备份一次，备份后，在钱包中便不会再显现。因此，在备份时肯定要誊写下去，防止誊写过失，尽量屡次检验。

5.Keystore：

Keystore+密码=私钥=银行卡号+银行卡密码、Keystore ≠?银行卡号

Keystore相当于加密事前的私钥,在导入钱包时，只需输入Keystore 和密码，就能进入钱包了。这一点和用私钥或助记词导入钱包不一样，后两者不需要知道原密码，而是直接重置密码。

keystore停止买卖转账等钱包操作,必需知道该keystore的密码。keystore的密码是无法更改的,一个keystore对应一个密码。但是可以经过该钱包的助记词,重重生成一个keystore。这个keystore可以用新的密码生成,重重生成新的keystore之后,最好将旧的keystore删除。

总结：

一个数字货币钱包创立完成后，公钥和私钥是成对出现的。公钥，私钥都是由字母，数字组成的较长的字符串。

keystore和助记词可以了解为私钥的另一种表现方式。助记词作为钱包私钥的友好格式，十分便利备份和导入。

地址可以经过私钥、助记词、keystore+密码，导入钱包找回。密码可以经过私钥、助记词，导入钱包重置密码。假设私钥、助记词、Keystore+密码，有一个音讯泄漏，他人就可以具有你钱包的掌握权，钱包内的币就会被他人转移走。

私钥经过加密生成公钥，公钥转换一下格式生成地址。私钥可以推导出公钥，公钥可以推导出地址，但无法通过输上天址、公钥推导出私钥。

在生活中，银行开户是“开设银行账户—银行卡号—设置银行卡密码—开户胜利

在币圈里，是先设置“密码”（私钥），再取得“银行账户”（公钥），最后给地址。关于钱包平安管理,主要留意防盗和防丢。防止私钥激进及丧失。

留意事项：

1.关于各种骗局诱导交出私钥、助记词的行为，都要慎重操作；

2.注重私钥、助记词、Keystore+密码的备份和保管！多重备份,屡次备份,多重考证，防止抄写过失。

3.私钥不好备份的状况下，可选用备份助记词，精细依据钱包的备份央求。

4.不要停止联网备份，或通过微信、qq、邮箱等任何第三方工具停止传输发送你的私钥、助记词、keystore。不要截图。

5.备份方式放到平安、妥善的中央，并通知家人（以防突发事故发生）

数字货币钱包的作用是安全存储资产，这是最主要的！从投资纪律来讲，本金安全是一切的基础。关于理财类的钱包，宣称赚取收益高报答等，应当叫“数字资产理财”更妥当。你的资产他们可以随意动用拿去投资。你对资产没有完整的掌控权，假设投资胜利，本息安全，假设投资失利，血本无归。所以，请慎重运用这类钱包，应当注重的是资产的安全和私密性。

公钥和私钥是通过一种算法取得的一个密钥对(即一个公钥和一个私钥)，将其中的一个向外界公开，称为公钥；另一个自己保管，称为私钥。通过这种算法失掉的密钥对能保证逝世界范围内是独一的。使用这个密钥对的时分，假设用其中一个密钥加密一段数据，必需用另一个密钥解密。比如用公钥加密数据就必需用私钥解密，假如用私钥加密也必需用公钥解密，否则解密将不会胜利。

本文触及到支付宝SDK的方式，均摘自支付宝封锁平台。

由于支付宝SDK运用RSA来加密和生成数字签名，所以本文中触及到的概念也都是针关于RSA的。

一对儿密钥生成后，会有公钥和私钥之分，我们需要把私钥保管下去，而把公钥公布进来。一对儿公钥和私钥，不能由其中一个导出另一个。

比方使用支付宝SDK的时分，我们商户端会生成一对儿密钥A和B，A是私钥，B是公钥，支付宝也会生成一对儿密钥C和D，C是私钥，D是公钥。我们商户端需要把商户端私钥A保管上去，而把商户端公钥B公布进来给支付宝，支付宝需要把支付宝私钥C保存上去，而把支付宝公钥D公布出去给我们商户端。

加密是指我们使用一对儿密钥中的一个来对数据加密，而使用另一个来对数据解密的技术，需要留意的是公钥和私钥都可以用来加密，也都可以用来解密 ，并不是规则死了只能用公钥加密私钥解密，但是加解密必需是一对儿密钥之间的相互加解密，否则不能胜利。

加密的手腕是为了保证数据的不可读性，防止数据在传输进程中被截获。

知道了加密这个概念，我们先看一下支付宝的加密进程，再引出数字签名这个概念。接着第1小节的例子，当我们商户端和支付宝相互公布了公钥之后，我们商户端手里就有 商户端私钥 和 支付宝公钥 两个密钥，支付宝手里也有 商户端公钥 和 支付宝私钥 两个密钥。往常假定我们商户端要给支付宝传输订单音讯，那么为了保证传输订单音讯时数据的安全性，区分我们商户端手里所具有的密钥，可以有两套加密计划

貌似这两套加密计划都能抵达对订单消息加密的效果，而且如果采用计划二，我们商户端甚至只需要存储支付宝公钥这一个密钥，都不用去央求一对儿商户端的公私钥来维护，支付宝也不用保存我们一堆商户那么多的商户端公钥了，这不是更冗杂吗，那为什么支付宝封锁平台让我们采用的是方案一而不是方案二呢？下面来回答一下。

支付宝封锁平台说明：当我们采用RSA（1024位密钥）来加密的时分，支付宝分配给一切商户的支付宝公钥都是一样的，即支付宝针对那么多的商户只负责维护一对儿支付宝公私钥，这就意味着支付宝公钥随意什么人拿到后都是一样的；而当我们采用RSA2（2048位密钥）来加密的时分，支付宝会分配给每个商户独自的一个支付宝公钥，即支付宝为每一个的商户独自的保护一对独立的支付宝公私钥，当然一个商户下的多个App的支付宝公钥是一样的。RSA是早就支持的，RSA2是最近才支持的。

知道了下面这段话，往常假定我们采用的是方案二，并且采用RSA加密（很多老业务并没有使用RSA2加密），业务逻辑将会是下面这样。

这就出效果了， RSA加密下，支付宝公钥是公开拓布的，而且一切的商户用的都是同一个支付宝公钥（下面声明了RSA2加密下，支付宝才针对每个商户维护了一对儿公私钥），攻击者很冗杂就能获取到，而 notify_url 也很繁杂被截获，那攻击者拿到这两个东西就可以做和商户一样的操作来发起支付央求，这样就会一直给小明充钱了。

所以 支付宝就需要确认支付恳求确实是商户发给他们的，而不是攻击者发给他们的。 这就用到了 数字签名 ，我们会通过方案一的完成流程来引出数字签名的精细概念。如果我们采用的是方案一，我们商户端保存的就是商户端私钥和支付宝公钥，而支付宝保存的就是需要存着商户端公钥和支付宝私钥的，业务逻辑将会是下面这样。

这样就可以保证买卖的安全性了，我们也可以看出使用支付宝SDK保证买卖的安全性重视的其实不是订单消息能否加密，而是如何确保商户端和支付宝可以互相确认身份，订单消息是明文的，但是前面拼接了数字签名。

数字签名其实就是明文数据加密之后失掉的一个密文，只不过它是用私钥加密生成的而已，我们一般会把数字签名拼接在明文数据前面一同传递给接收方，接收方收到后用公钥解密数字签名，从而考证发送方的身份、以及明文数据能否被窜改。数字签名的生成进程其实就是一个加密进程，数字签名的验签进程就是一个解密进程。

数字签名的手腕有两个：一、发送方和接收方互相考证身份；二、考证数据能否被窜改。

从上面第一局部我们知道为了确保商户和支付宝买卖的安全性，商定采用的是给订单消息加数字签名传输的方式。支付宝也为我们提供了 一键生成RSA密钥的工具 ，可以辅佐我们很快的生成一对商户端公私钥。以下会对支付宝SDK的支付流程做个大约的注释，并点出实际开拓中我们使用支付宝SDK时应当留意的中央。

由我们商户端自己生成的RSA私钥（必须与商户端公钥是一对），生成后要保具有效力端，相对不能保具有客户端，也相对不能从效力端传输给客户端。

用来对订单消息加签，加签过程肯定要在效力端完成，绝对不能在客户端做加，客户端只负责用加签后的订单信息调起支付宝来支付。

由我们商户端自己生成的RSA公钥（必须与商户端私钥是一对），生成后需要填写在支付宝封锁平台。

用来给支付宝效劳端验签经过我们加签后的订单信息，以确保订单信息确实是我们商户端发给支付宝的，并且确保订单信息在传输过程中未被窜改。

这个和我们就没联系了，支付宝私钥是他们自己生成的，也是他们自己保存的。

用来对支付结果停止加签。

支付宝公钥和支付宝私钥是一对，也是支付宝生成的，当我们把商户端公钥填写在支付宝封锁平台后，平台就会给我们生成一个支付宝公钥，我们可以复制上去保具有效劳端，非常不要保具有客户端，并且不要传输给客户端。

用来让效劳端对支付宝服务端返给我们的同步或异步支付结果停止验签，以确保支付结果确实是由支付宝服务端返给我们服务端的，而且没有被窜改，对支付后果的验签义务也肯定要在服务端完成。

上面曾经说过了： 订单信息的加签和支付后果的验签是肯定要在服务端做的，绝对不能在客户端做。

下面是在客户端对订单信息加签的过程，仅仅是为了模拟服务端来标明订单信息是如何通过加签最终改动为orderString的， 千万不要觉得订单信息的加签过程也可以放在客户端完成 。

假定我们服务端收到了来自支付宝服务端的支付结果，即： 支付结果+数字签名 。

那么我们服务端就会对支付结果进行验签，怎样个验法呢？