在 SegmentFault，解决技术问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
一线的工程师、著名开源项目的作者们，都在这里：
获取验证码
已有账号？
标签：至少1个，最多5个
Android安全之Https中间人攻击漏洞
HTTPS，是一种网络安全传输协议，利用SSL/TLS来对数据包进行加密,以提供对网络服务器的身份认证，保护交换数据的隐私与完整性。中间人攻击，Man-in-the-middle attack，缩写：MITM，是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。https在理论上是可以抵御MITM，但是由于开发过程中的编码不规范，导致https可能存在MITM攻击风险，攻击者可以解密、篡改https数据。
0X02 https漏洞
Android https的开发过程中常见的安全缺陷:1)在自定义实现X509TrustManager时，checkServerTrusted中没有检查证书是否可信，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。2)在重写WebViewClient的onReceivedSslError方法时，调用proceed忽略证书验证错误信息继续加载页面，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。3)在自定义实现HostnameVerifier时，没有在verify中进行严格证书校验，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。4)在setHostnameVerifier方法中使用ALLOW_ALL_HOSTNAME_VERIFIER，信任所有Hostname，导致通信过程中可能存在中间人攻击，造成敏感数据劫持危害。
0X03 漏洞案例
案例一：京东金融MITM漏洞京东金融Ver 2.8.0由于证书校验有缺陷，导致https中间人攻击，攻击者直接可以获取到会话中敏感数据的加密秘钥，另外由于APP没有做应用加固或混淆，因此可以轻松分析出解密算法，利用获取到的key解密敏感数据。御安全扫描结果：
如下是登陆过程中捕获到的数据：
其中的secretkey用于加密后期通信过程中的敏感数据，由于APP中使用的是对称加密，攻击者可以还原所有的通信数据。 案例二：中国移动和包任意消费漏洞HTTPS证书校验不严格，可被MITM；加密算法不安全，可被破解；关键数据保存在sdcard卡上，可被任意访问；代码混淆度低，业务逻辑，关键数据泄漏；消息签名算法比较简单，数据可被修改；通信数据如下：
POST :28710/ccaweb/CCLIMCA4/2201194.dor HTTP/1.1
Cookie: JSESSIONID=CHGmYSZLTMRAx_1sSEuUP6Q4vmRI9gWiRPM6ANGnH7eZWv0NhErE!
Content-Length: 521
Host: :28710
Connection: Keep-Alive
Cookie: JSESSIONID=CHGmYSZLTMRAx_1sSEuUP6Q4vmRI9gWiRPM6ANGnH7eZWv0NhErE!
Cookie2: $Version=1
&?xml version="1.0" encoding="UTF-8" ?&&ROOT&&HEAD&&IMEI&260&/IMEI&&MCID&185gye5tKk6EPB4iliO7&/MCID&&TXNCD&2201194&/TXNCD&&VERSION &4.3.82&/VERSION &&UA&Android_21--HUAWEI GRA_UL10&/UA&&SOURCE&2009&/SOURCE&&PLAT&3&/PLAT&&DEVID&CAS00016&/DEVID&&SERLNO&991&/SERLNO&&/HEAD&&BODY&&IMEI&260&/IMEI&&ENTRY&10&/ENTRY&&MAC&50:a7:2b:c5:e2:d8&/MA
在用户开启免密支付的前提下，结合以上安全问题，可以实现本地或远程攻击，直接盗取和包用户资金，如给任意账号充值等，给用户带来直接经济损失。
0X04 安全建议
1) 建议自定义实现X509TrustManager时，在checkServerTrusted中对服务器信息进行严格校验2)在重写WebViewClient的onReceivedSslError方法时，避免调用proceed忽略证书验证错误信息继续加载页面3)在自定义实现HostnameVerifier时，在verify中对Hostname进行严格校验4)建议setHostnameVerifier方法中使用STRICT_HOSTNAME_VERIFIER进行严格证书校验，避免使用ALLOW_ALL_HOSTNAME_VERIFIER
（腾讯御安全技术博客）
0 收藏&&|&&1
你可能感兴趣的文章
1 收藏，1.9k
3 收藏，1.5k
本作品采用 署名-非商业性使用-禁止演绎 4.0 国际许可协议 进行许可
分享到微博？
我要该，理由是：博客分类：
最近，Google针对Gmail被攻击事件， 全面默认启用了始终以https访问Gmail的方式了。但是，对于可以动用整个国家力量的黑客来说，从网络通讯数据中（在此不讨论对用户电脑种木马破解 https的情况，只讨论在网络通讯数据中破解https的方法）破解https除了暴力破解（暴力破解https即使按照现在的集群计算能力仍旧需要几 百至几万年不等）之外真的别无他法了吗？事实并非如此。
　　我们知道，https的安全性主要是由SSL证书中的公钥和私钥来保证的。浏览器与服务器经过https建立通讯的时候（不考虑SSL代理方式需要用户提交证书的情况，因为我们现在讨论的是浏览器访问网站，和SSL代理无关）会按照以下步骤保证通讯的安全性：
　　1、浏览器连接服务器，服务器把SSL证书的公钥发送给浏览器
　　2、浏览器验证此证书中的域是否和访问的域一致（比如用户访问/时，浏览器验证服务器发送过来的SSL证书的公钥中的域是否为或*.）并没有过期
　　3、如果浏览器验证失败，浏览器通知用户证书有问题，让用户选择是否继续
　　4、如果浏览器验证成功，那么浏览器随机生成一个对称密钥并使用接收到的SSL证书的公钥进行加密并发送给服务器
　　5、服务器通过SSL证书的私钥对收到的信息进行解密并得到浏览器随机生成的对称密钥
　　6、最后服务器和浏览器都通过这个对称密钥进行通讯了（为什么不直接使用公钥和私钥进行通讯？因为非对称加密比对称加密效率低）
　　这个方案看似完美，却无法抵御中间人攻击，攻击者可以按以下步骤实施攻击截取https通讯中的所有数据：
　　1、攻击者伪造一个Gmail的SSL证书，使其中的域为或*.，并设置合适的证书过期时间
　　2、攻击者等待访问者的浏览器访问Gmail时，通过DNS劫持或IP伪造（对于有路由器控制权限的黑客来说简直轻而易举）的方法使其访问到攻击者的服务器上
　　3、攻击者把伪造的SSL证书公钥发送给浏览器
　　4、浏览器验证SSL证书的域和过期时间都没错，认为访问到的就是Gmail本身，从而把对称密钥发送给黑客服务器
　　5、黑客服务器把伪造的Gmail网页通过收到的对称密钥加密后发送给浏览器
　　6、访问者通过浏览器输入Gmail帐户，发送给黑客服务器，黑客服务器通过收到的对称密钥解密后成功获得访问者的Gmail密码
　 　为了抵御这种中间人攻击，SSL证书需要由可信的SSL证书颁发机构颁发，形成一个证书链（比如Gmail的证书链为：最底层为网域 ，上一层为Thawte SGC CA证书颁发机构，最顶层为很有名的VeriSign证书颁发机构）。那么，浏览器除了需要验证域和有效期外，还要检查证书链中的上级证书公钥是否有效， 上级的上级证书公钥是否有效，直至根证书公钥为止。这样就可以有效避免中间人攻击了，因为根证书公钥都是预装在操作系统中的，黑客如果不是暴力破解，无法 得到根证书的私钥，如果黑客自己生成一个私钥，浏览器验证根证书公钥的时候发现无法通过操作系统中预装的公钥加密数据后使用这个私钥进行解密，从而判定这 个公钥是无效的。这个方案也是现在https通讯通常的方案。
　　那么，这个现在所有的浏览器正在使用的https通讯方案就无懈可击了 吗？答案仍是否定的。我们可以看到，在后一个方案中，https的安全性需要在证书颁发机构公信力的强有力保障前提下才能发挥作用。如果证书颁发机构在没 有验证黑客为的持游者的情况下，给黑客颁发了网域为的证书，那么黑客的中间人攻击又可以顺 利实施：
　　1、攻击者从一家不验证持有者的SSL证书颁发机构WoSign那里得到了网域为 的证书，此证书的证书链为：最底层为网域，上一层证书颁发机构为WoSign，顶层证书颁 发机构为VeriSign
　　2/3、第二、第三个步骤同上一个方案的中间人攻击的第二、第三个步骤
　　4、浏览器验证SSL证书的域和过期时间都没错，继续验证证书链：
　　　　4.1、最底层的网域证书公钥不在操作系统中，无法验证其访问到的就是Gmail本身，继续验证上一层证书颁发机构
　　　　4.2、上一层证书颁发机构WoSign的公钥也不在操作系统中，仍旧无法验证其有效性，继续验证上一层证书颁发机构
　　　　4.3、浏览器看到顶层证书颁发机构VeriSign的公钥在操作系统中，认为证书链有效，从而把对称密钥发送给黑客服务器
　　5/6、第五、第六个步骤同上一个方案的中间人攻击的第五、第六个步骤。黑客成功获得访问者的Gmail密码
　 　然而，不验证域名持有者就颁发证书的情况在国外几乎不会发生，但是在国内就不一定了。针对破解目标，国内证书颁发机构WoSign（在此只是举例国内比 较有名的证书颁发机构WoSign，并不代表WoSign今后一定会这么做）很有可能为了上级要求颁发了证书给非域名持有者的黑客，从而使得破解目标的 Gmail密码被黑客截取。
本文转载自：/archives/2058.html
浏览: 73173 次
来自: 济南
XMLInputFactory2 xmlif = (XMLIn ...
SSL证书怎么伪造啊...有数字签名的啊...
若把此问题交给oracle的sequence来解决岂不是很简单 ...
写的时候，考虑过用indexof查一次，删一次，后来写着写着就 ...
我一开始用的stringbuffer，发现删除了那些不需要的h ...
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'针对SSL的中间人攻击演示和防范 - CSDN博客
针对SSL的中间人攻击演示和防范
1 中间人攻击概述
中间人攻击（-in-the-Middle
Attack, MITM）是一种由来已久的网络入侵手段，并且在今天仍然有着广泛的发展空间，如SMB会话劫持、DNS欺骗等攻击都是典型的MITM攻击。简而言之，所谓的MITM攻击就是通过拦截正常的网络通信数据，并进行数据篡改和嗅探，而通信的双方却毫不知情。
随着计算机通信网技术的不断发展，MITM攻击也越来越多样化。最初，攻击者只要将网卡设为混杂模式，伪装成代理服务器监听特定的流量就可以实现攻击，这是因为很多通信协议都是以明文来进行传输的，如HTTP、、等。后来，随着交换机代替集线器，简单的嗅探攻击已经不能成功，必须先进行欺骗才行。如今，越来越多的服务商（网上银行，邮箱登陆）开始采用加密通信，SSL(Secure
Sockets Layer 安全套接层)是一种广泛使用的技术，HTTPS、FTPS等都是建立在其基础上的。笔者将以常见的Gmail邮箱登陆为例，探讨针对SSL的MITM攻击的两种实现方式。
2 &环境的搭建
网络环境：
攻击目标：
3 两种针对SSL的中间人攻击
Cain & Abel
Cain&Abel是由Oxid.it公司开发的一款针对Microsoft操作系统的网络攻击利器，它操作简单、功能强大，尤以ARP欺骗攻击著称。Cain不仅能实现针对HTTP的MITM攻击，也能对HTTPS进行攻击。基本的攻击过程为：
由于SSL握手时要通过证书来验证彼此的身份，攻击者并不知道目标服务器所使用的私钥，在这种情况下，要成功实施攻击，攻击者必须进行证书的伪造，浏览器通常会向用户发出警告，并由用户自行决定是否信任该证书。下面进行详细的图文说明。
正常Gmail的登陆画面。
被攻击者需要选择是否信任证书，可以看到伪造的证书信息与上图中真实证书还是有很大的区别的。
登陆邮箱后的画面，可以看到证书错误的提示依然是很醒目的。
攻击者已成功嗅探到Gmail邮箱的登陆用户名和密码。
&通过以上分析可以发现，用户对于伪造证书的判断是攻击能否成功的关键，如果用户有着较强的安全意识和丰富的网络知识那么被攻击的可能性将大大降低，毕竟浏览器中的安全提示还是非常醒目的。笔者相信随着网络知识的不断普及，这种攻击手段的生存空间会不断被挤压。
Cain & Abel虽然能实现SSL攻击，但是伪造证书的局限性还是很明显的， sslstrip是在09年黑帽大会上由Moxie Marlinspike提出的一种针对SSL攻击的方法，其思想非常简单：
笔者将采用BackTrack作为攻击平台，BackTrack是基于的一套渗透测试工具包，目前，国内各大论坛有很多关于使用BackTrack来进行无线wifi密码破解的教程，其实它在其他领域也有着极其强大的功能。
步骤一：启用内核包转发，修改/proc/sys/net/ipv4/ip_forward文件，内容为1;
1 & /proc/sys/net/ipv4/ip_forward
步骤二：端口转发，10000为sslstrip的监听端口；
-t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 10000
步骤三：shell1，ARP欺骗；
# arpspoof -i eth0 -t 192.168.18.100 192.168.18.254
步骤四：shell2，开启sslstrip；
# sslstrip -a -k -f
步骤五：嗅探得到登陆Gmail邮箱的用户名和密码；
# ettercap -T -q -i eth0
那么这种方法是否是万能的呢，下面就来看看被攻击者浏览器的变化。
可以看到，网页上没有任何不安全的警告或是提示，只是原先的HTTPS连接已经被HTTP连接所替换，并且为增加迷惑性，网页的图标被修改成了一个银色的锁图案。但是，假的毕竟是假的，一方面无法查看到任何证书的信息，另外如果在网址前输入https://，则网页无法发开。因此，sslstrip并不是万能的攻击方法。
本文的目的主要是想告诉读者，网络安全技术日新月异的同时，攻击方法也在悄然发生着变化，采用了SSL加密通信并不一定能保证通信的隐密性和完整性，为此，笔者展示了两种SSL的中间人攻击方法，前者是常规思路，后者则另辟蹊径。希望今后大家能提高警惕，准确辨识你的通信是否正遭到攻击，尤其是在完成重要操作时，如网银交易等。
原文地址：http://www.linuxde.net/2.html
本文已收录于以下专栏：
相关文章推荐
作者：行里1.
Android HTTPS中间人劫持漏洞描述
在密码学和计算机安全领域中，中间人攻击 （ Man-in-the-middle attack，通常缩写为MITM ）是指攻击者与通...
HTTPS，是一种网络安全传输协议，利用SSL/TLS来对数据包进行加密,以提供对网络服务器的身份认证，保护交换数据的隐私与完整性。
中间人攻击，Man-in-the-middle attack，缩写...
BT5r3下初探中间人攻击，ARP欺骗aprspoof或ettercap，DNS欺骗，hamster会话劫持，SSL会话劫持
SSL中间人攻击                     
攻击者位于客户端和服务器通信链路中
相关文章：
中间人攻击(Man-In-The-Middle)&&Cain使用简介
中间人攻击·百度百科
中间人攻击·维基百科
Man-in-the-middle attack
中间人攻击 &...
中间人攻击（Man-in-the-Middle Attack，简称“MITM攻击”）是一种“间接”的入侵攻击， 这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计...
老板要求，实验几个ssl中间人攻击的工具，简单的记录下实验过程和一些简单的原理，已经使用过的几个工具的使用方法和特点，以备使用。
实验环境：
操作系统：kali-linux虚拟机
IP地址：...
其实很简单，假设没有这一过程，那么一个恶意的第三方就可以在握手时截取通信数据，对于用户，假装成服务器；对于服务器，假装成用户。当第三方成功插入用户和服务器之间时，加密就形同虚设了，第三方可以轻易解密所...
一、安装ettercap
要安装ettercap，需要先安装：
1.libnet-1.1.2.1.tar.gz
2.libpcap-1.0.0.tar.gz
3.ettercap-NG-0.7...
关于Https安全性问题、双向验证防止中间人攻击问题最近项目中遇到一个问题，安全测试时反馈出，利用fiddler截取到了客户端与后台的https接口的明文内容，这是一个可怕的问题，那么接下来我从下面几...
他的最新文章
讲师：王禹华
讲师：宋宝华
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)请问如何防范中间人攻击
20:33:33 +08:00 · 5481 次点击
作为一个局域网的普通用户，没有路由管理权，请问各位，如何能够识别中间人攻击（ip重复冲突？看arp表？），并防范阻止？
32 回复 &| &直到
19:44:06 +08:00
& & 20:43:15 +08:00 via iPad
攻击者如果有交换机权限，没有办法防范吧？
如果没有权限，通常用arp sproofing吧，这时，除了arp绑定就没有其他办法了吧？
& & 20:55:24 +08:00
& & 20:59:03 +08:00 via iPhone
& & 21:00:02 +08:00
@ 那么请问除了建立在SSL/TLS协议以外的协议都是不安全无法防范的？
& & 21:03:53 +08:00 via iPhone
Ssl也可以中间人，只要有一个可信ca的签发权就行了
& & 21:10:26 +08:00
@ 这个似乎是之前新闻里微软一个下属软件开发的伪造了可信证书。。。似乎一般ssl中间人是通过SSLStrip这类软件降级处理吧
& & 21:12:53 +08:00 via iPhone
@ 我随便举个栗子。
CNNIC就可以拿来做中间人。(做没做我们不讨论。
& & 21:14:09 +08:00
@ IPSec, ssh 这些也是可以抵抗 MITM 攻击的，有可靠的消息认证就行。
& & 21:31:26 +08:00
同意楼上，一般能防MITM的要具有以下特征：
1、握手加密而且具有可信CA（SSL、TLS之类，CNNIC和WoSign就不点评了）或拥有预协商密钥（L2TP）
2、加密方法足够强大（AES、CHACHA20之类，RC4和SM2就不点评了）
综上，一般情况下，以下的协议是安全的：
1、HTTPS（排除RC4、3DES算法，排除CNNIC、WoSign的CA证书）
2、OpenVPN（基于TLS，只要你能连上就是安全的）
3、L2TP *Over IPSec*（必须要Over IPSec，没了就没加密了）
4、IKEv2（基于TLS和可信CA发的证书，安全性比OpenVPN还好）
5、SSTP（基于TLS和可信CA发的证书，安全性和IKEv2相同，稳定性加强，用443端口）
6、ShadowSocks（基于N+1种加密算法，只要你不选RC4或RC4-MD5算法就是安全的）
7、任何用SSL Stream过又验证CA甚至客户端证书的TCP连接（UDP大家都懂，DNS什么的）
& & 21:32:11 +08:00
当然，SSH也算一个
& & 21:37:26 +08:00
感谢，受教了！
& & 21:48:22 +08:00 via Android
@ 谢谢提醒没关手机里面的cnnic和wosign
为什么rc4-md5还不安全呢？
& & 21:58:46 +08:00 via iPhone
@ SSLstrip能使通信失去证书，加了HSTS特性的网站会报错（chrome根本不给你打开网页的机会，即使你想继续也不行）
& & 22:03:35 +08:00
@ RC4_MD5为什么不安全？
& & 22:09:02 +08:00
嘛，简单点说好了。
ShadowSocks的RC4不安全是因为Key复用的问题，也就是算法有问题，RC4-MD5上已经修复了这个问题了。
RC4-MD5不安全的原因是因为加密强度太弱，主要是给ARM或MIPS架构的CPU（也就是手机和路由器）准备的，正常情况下使用是没问题的（因为当年clowwindy说过ShadowSocks的加密是为了模糊流量，不是为了加密而加密），但是要遇上曙光4000暴解的话估计也就数分钟的事（不过估计也要等到你干了什么不惜动用曙光4000也要把快递送到你家门口的事再说）。
& & 22:22:32 +08:00
现在浏览器增加的Public Key Pinning 功能也可以应对这种攻击吧?
& & 22:32:21 +08:00
@ 不能认为 shadowsocks 是安全的. shadowsocks 只有加密，没有认证。中间人可以篡改数据，在使用流加密算法时这个问题尤其严重。
& & 22:55:51 +08:00 via Android
@ 那chacha20在mips上面的性能如何？
& & 23:08:05 +08:00
@ 中间人如何知道shadowsocks的密钥
& & 23:24:58 +08:00
@ 似乎看到了熟人
& & 00:49:57 +08:00
这是啥上网环境啊。遇到这种环境，我一般把设备wifi功能关了。然后看看书。
就算你是大侠，也不应该在这种环境里凑热闹。熟话说的好，乱棍打死老师傅。
别以为自己做了某些措施就安全了。
& & 01:50:52 +08:00
@ 可是现实也有很多这样的环境，街边的麦当劳，甜品店的wifi很有可能就是这样的环境，所以有时候重视讨论一下还是挺好的。。。。。
& & 02:08:52 +08:00
@ 曙光4000暴解根本是一件不用担心的事情了……与其花大笔计算费用，还不如一个快递让你进去交代。除非你在国外，但如果在国外，翻墙干啥？
& & 12:32:40 +08:00 via Android
一是防范路由链路不被中间人劫持，静态arp绑定，静态路由，关闭代理自动发现功能等等。不过要是人家直接控制了路由器，这些都没用了。
二是防范流量被中间人解密和篡改，那就是上面的各种办法了。https不算安全，它可以被降级成http或者被中间人替换证书。
关于gfw能解密哪些协议的问题，大家可以找些敏感词去测试一下。
& & 13:52:29 +08:00
@ 这里交代一下，我并不是对网络安全不重视。其实我就是做网络安全的。
我给出上面的答案，是因为我对安全更加敏感。对小白用户说，也是最好的选择。
既然你说到这样的问题了，我就说说逼不得已的时候我是怎么处理的。
首先在开机之后，静止几秒。因为这时候很多软件都开始尝试联网，获取ip，获取dns。你现在着急联网，秒被路由“下毒”。等1-2分钟，数据请求不密集时，登录wifi，并且秒登录vpn。注意：一定要全局加密。用shadowsocks这种，你的QQ等还是暴漏在外面的。vpn的加密等级最好高一点，推荐openvpn。
接下来你的所有数据都走vpn，路由上可以抓到的数据都是你的笔记本与vpn的加密信息。目前这种加密无解，你可以放心了吧。
& & 14:12:41 +08:00
@ 修改数据不需要密钥。对于任意的流加密算法，记明文为 P, 密钥流为 KS, 密文为 E. 有
E = P Xor KS
假设攻击者知道密文 E, 明文中某个字段的位置和值 P[begin:end], 想要把明文中的对应字段篡改为 M[begin:end], 只要计算出差异
DIFF = M[begin:end] Xor P[begin:end]
就可以再计算一个
ME = E
ME[begin:end] = E[begin:end] Xor DIFF
这样生成的 ME 就能够被解密成篡改后的明文，达到了在不知道密钥的情况下破坏数据完整性的目的。
就针对 shadowsocks 来说，攻击者可以猜测协议中的目的地址字段，将它修改成攻击者控制的服务器，然后 ssserver 就把解密的数据发送给攻击者了。
shadowsocks 只是一个混淆协议，不是安全协议。
& & 16:22:56 +08:00
@ orz吊吊吊
& & 16:58:40 +08:00
@ 点评下SM2
& & 19:24:09 +08:00
根据偶的印象，为了避免探测，ShadowSocks会把无法解密的数据拿去扔掉，根本不会理会（但会把连接失败写到系统日志里）。而且每一个连接的密钥都是基于初始向量单独生成的,不同的链接之间也不会共用密码，即使猜到了密码也没用，只能暴解但个连接的实际密码。密码方面，采用和L2TP预协商密钥类似的密码方法是可以达到加密的效果的，只要加密强度足够大，解密也是需要时间的，何况还要把密码给md5一遍以增加长度。
参见：[](/shadowsocks/shadowsocks/blob/master/shadowsocks/encrypt.py)
很遗憾，手头没有可以测试MIPS设备。（唯一的TP-LINK也被母上大人命令不准破坏，目前智能路由之类的功能都是用开发板充当网关实现的）但是ChaCha20对于精简指令集的CPU有优化是真的，性能虽不及RC4，但是比AES是好多了。而且主要是因为安全性有保障，要不Google也不会在移动端HTTPS用CHACHA20-POLY1305。（使用移动版Chrome开，注意是Chrome，其余浏览器无效）
嘛，这个，法庭上要讲证据。
至于为什么身在人间也要翻墙回天朝的原因其实也很简单，大家要上B站看番。
目前的应用情况太少，实际的加密强度尚不明确（与AES的使用范围相比真是冰山一角），且算法持有人略坑，不排除持有某些未公开漏洞的可能。如果属实那查水表就太方便了。
& & 09:07:42 +08:00
@ 不知你所述的SM2是否为商密2号算法，此算法为非对称算法，基于ECC，曲线已公开，SM1未公开
& & 18:48:07 +08:00
就是那个东西，论文看过了，感觉也不怎么样，和ECDSA差不多的感觉，但并未明确指出解密年限。而且，由于应用范围过窄，不知道是否会出现魔数。这种东西必须要大量验证以后才可以被信任，而且发明者偶觉得完全不可信。建议目前还是用ECDSA或者RSA。
& & 19:44:06 +08:00
@ SM2就是选了条ECC 256的曲线，然后运算中掺杂了点SM3进来。SM2是定长签名算法，就好像RSA1024，解密年限这东西，参见ECC强度吧。既然是开源的，就没有可信不可信的说法了吧，而且算法这东西，不是大量验证，而是长时间的开源审计吧。
& · & 1686 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.0 · 39ms · UTC 15:07 · PVG 23:07 · LAX 07:07 · JFK 10:07? Do have faith in what you're doing.}