私钥破解,私钥破解软件

如何保证钱包私钥安全

对于数字货币钱包来说，它并不是装钱的，而是装密钥的工具，准确来说，就是装私钥的工具。有了私钥就可以拥有根据其对应公钥计算出的地址上的数字货币的支配权。

作为钱包开发者，如何存储和使用用户私钥便是钱包安全的关键所在。

下面是使用imToken钱包App创建钱包的截图。从截图上可以清楚的看到我们在钱包的时候需要输入密码来保护私钥。那这个私钥究竟是如何被保护的呢？私钥的生成和输入的密码有没有关系呢？

这里一般有两种误解：

如果钱包应用开发者真的这么做的话，估计大家每天都是排着队丢币了 :)。

你想啊，如果是之一种情况，那如果两个人用同样的密码不就可以互相看到对方钱包了么。

如果是第二种情况，在你输入密码进入钱包应用后，私钥就要被加载并驻留在内存里。你在网上搜一下“从内存提取密码工具”，保证可以搜到一大把。另外一个风险是，用户输入的密码都不是太长并且很多时候有规律可循，这样当加密后的私钥数据泄漏后，黑客通过暴力破解结合彩虹表等工具将私钥破解的几率还是比较高的。

事实上，私钥的生成永远和你输入的密码没有半毛钱关系，要么是随机生成，要么是根据助记符（一串随机生成的英文或其它语言词组）生成，保证每个人的私钥都是唯一的。

私钥的加密过程一般来说是下面这样的：

之一步：钱包应用会生成一个32字节随机数，我们称之为主密钥。

第二步：使用用户输入的密码对主密钥加密，生成主密钥密文。

第三步：使用主密钥对钱包私钥进行加密，生成私钥密文。

第四步：清除主密钥和私钥，保留主密钥密文和私钥密文。

你可以会有疑问，这样黑客拿到密文后先暴力破解主密钥，再破解私钥不也很容易么？其实在具体实现的时候，每个密文在生成的时候不只是用输入的密码，还有相应的密文生成参数，想通过密文和密码直接解密得到明文没那么容易的。

从上一部分的解释我们知道，钱包应用里保存的是主密钥密文和私钥密文。

当我们登录钱包后，钱包应用会通过我们输入的密码对主密钥密文解密，将解密后的主密钥驻留内存。

当我们进行转账等需要私钥签名的操作时，通过主密钥解密私钥密文得到私钥，使用后立即将私钥从内存清除。

当我们需要修改密码时，实际上只是修改了主密钥密文，并不会触碰私钥相关部分。

这样，基本上将私钥明文暴露的几率降到更低，更大限度的保证私钥的安全。

还有疑问？欢迎加入我的知识星球，尽我所能为你答疑解惑。

怎样实现对私钥（公钥）进行解密？

要实现安全登录，可以采用下面三种 *** ，一种基于非对称加密算法，一种基于对称加密算法，最后一种基于散列算法。下面我们来分别讨论这三种 *** 。

非对称加密算法中，目前最常用的是 RSA 算法和 ECC（椭圆曲线加密）算法。要采用非对称加密算法实现安全登录的话，首先需要在客户端向服务器端请求登录页面时，服务器生成公钥和私钥，然后将公钥随登录页面一起传递给客户端浏览器，当用户输入完用户名密码点击登录时，登录页面中的 JavaScript 调用非对称加密算法对用户名和密码用用公钥进行加密。然后再提交到服务器端，服务器端利用私钥进行解密，再跟数据库中的用户名密码进行比较，如果一致，则登录成功，否则登录失败。

看上去很简单，但是这里有这样几个问题。目前 RSA 算法中，1024－2048 位的密钥被认为是安全的。如果密钥长度小于这个长度，则认为可以被破解。但这样的长度超过了程序设计语言本身所允许的数字运算范围，需要通过模拟来实现大数运算。而在 Web 系统的客户端，如果通过 JavaScript 来模拟大数运行的话，效率将会是很低的，因此要在客户端采用这样的密钥来加密数据的话，许多浏览器会发出执行时间过长，停止运行的警告。然而，解密或者密钥生成的时间相对于加密来说要更长。虽然解密和密钥生成是在服务器端执行的，但是如果服务器端是 PHP、ASP 这样的脚本语言的话，它们也将很难胜任这样的工作。ECC 算法的密钥长度要求比 RSA 算法要低一些，ECC 算法中 160 位的密钥长度被认为与 RSA 算法中 1024 位的密钥长度的安全性是等价的。虽然仍然要涉及的模拟大数运算，但 ECC 算法的密钥长度的运算量还算是可以接受的，但是 ECC 算法比 RSA 算法要复杂的多，因此实现起来也很困难。

对称加密算法比非对称加密算法要快得多，但是对称加密算法需要数据发送方和接受方共用一个密钥，密钥是不能通过不安全的 *** 直接传递的，否则密钥和加密以后的数据如果同时监听到的话，入侵者就可以直接利用监听到的密钥来对加密后的信息进行解密了。

那是不是就不能通过对称加密算法实现安全登录呢？其实只要通过密钥交换算法就可以实现安全登录了，常用的密钥交换算法是 Diffie-Hellman 密钥交换算法。我们可以这样来实现密钥的安全传递，首先在客户端向服务器端请求登录页面时，服务器端生成一个大素数 p，它的本原根 g，另外生成一个随机数 Xa，然后计算出 Ya = gXa mod p，将 p、g、Ya 连同登录页面一起发送给客户端，然后客户端也生成一个随机数 Xb，计算 Yb = gXb mod p，然后再计算 K = YaXb mod p，现在 K 就是密钥，接下来就可以用 K 作密钥，用对称加密算法对用户输入进行加密了，然后将加密后的信息连同计算出来的 Yb 一同发送给服务器端，服务器端计算 K = YbXa mod p，这样就可以得到跟客户端相同的密钥 K 了，最后用客户端加密算法的相应解密算法，就可以在服务器端将加密信息进行解密了，信息解密以后进行比较，一致则登录成功，否则登录失败。需要注意的时候，这里服务器端生成的随机数 Xa 和 客户端生成的随机数 Xb 都不传递给对方。传递的数据只有 p、g、Ya、Yb 和加密后的数据。

但是如果我们不采用加密算法而采用散列算法对登录密码进行处理的话，可以避免被直接解密出原文，但是如果直接采用 MD5 或者 SHA1 来对登录密码进行处理后提交的话，一旦入侵者监听到散列后的密码，则不需要解密出原文，直接将监听到的数据提交给服务器，就可以实现入侵的目的了。而且，目前 MD5 算法已被破解，SHA1 算法则被证明从理论上可破解，就算采用离线碰撞，也可以找出与原密码等价的密码来。所以直接采用 MD5 或者 SHA1 来对密码进行散列处理也是不可行的。

但是如果在散列算法中加入了密钥，情况就不一样了。hmac 算法正好作了这样的事情，下面我们来看看如何用 hmac 算法实现安全登录。首先在客户端向服务器端请求登录页面时，服务器端生成一个随机字符串，连同登录页面一同发送给客户端浏览器，当用户输入完用户名密码后，将密码采用 MD5 或者 SHA1 来生成散列值作为密钥，服务器端发送来的随机字符串作为消息数据，进行 hmac 运算。然后将结果提交给服务器。之所以要对用户输入的密码进行散列后再作为密钥，而不是直接作为密钥，是为了保证密钥足够长，而又不会太长。服务器端接受到客户端提交的数据后，将保存在服务器端的随机字符串和用户密码进行相同的运算，然后进行比较，如果结果一致，则认为登录成功，否则登录失败。当然如果不用 hmac 算法，直接将密码和服务器端生成的随机数合并以后再做 MD5 或者 SHA1，应该也是可以的。

这里客户端每次请求时服务器端发送的随机字符串都是不同的，因此即使入侵者监听到了这个随机字符串和加密后的提交的数据，它也无法再次提交相同的数据通过验证。而且通过监听到的数据也无法计算出密钥，所以也就无法伪造登录信息了。

对称和非对称加密算法不仅适用于登录验证，还适合用于最初的密码设置和以后密码修改的过程中，而散列算法仅适用于登录验证。但是散列算法要比对称和非对称加密算法效率高。

bip38私钥会被破解

会被破解。因为ISE在实验中发现，由于一些生成私钥的钱包软件编码存在错误，导致产生的私钥随机性不高，容易被计算机暴力破解(枚举所有的可能性)。