常用加／解密技术

通常把加密方法分为以下几类

       1.单向加密算法 顾名思义，这种算法只能加密，不能解密，是不可逆的，所以叫做单向加密算法。这些算法又称摘要算法，就类似给一篇短文做一个提纲一样。相同的短文，做出来 的提纲是相同的，因此，可以根据提纲来判断是不是那个短文；又因为只有提纲，是无法知道原来的短文具体是怎么写的，所以又是不可逆的。

       所以这种算法通常被用作对数据进行签名。

       1.MD5(Message Digest algorithm 5，信息摘要算法)

       2.SHA(Secure Hash Algorithm，安全散列算法)

       3.HMAC(Hash Message Authentication Code，散列消息鉴别码)

       MD5、SHA、HMAC这三种加密算法，通常只把他们作为加密的基础。单纯的以上三种的加密并不可靠，通常与其他对称或非对称加密算法一起使用。 例如：

       Signature dsa = Signature.getInstance("SHA1withRSA");

       SHA1withRSA就是说明这是通过SHA1算法签名并通过RSA算法加密之后得到签名（也叫文件摘要）的方式。

       还有一种算法经常在加解密时使用， BASE64算法，BASE64严格地说，属于编码格式，而非加密算法。这种算法用于把字节数组转化成字符串，方便存储和传输和阅读。

2.对称加密算法
   对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥和解密密钥是相同的，或者加密/解密密钥能够从解密/加密密钥中推算出来，所以也称这种加密算法为秘密密钥算法或单密钥算法。
   对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。
   常见对称加密算法如下：
   1.DES算法
   2.3DES/edeDES/TDES算法
   3.AES算法
   4.Twofish算法
   5.Blowfish算法
   6.RC2算法
   7.RC4算法
   8.RC5算法
   9.RC6算法
   10.PBE算法
   11.CAST算法
   12.IDEA算法
3.非对称加密算法
   非对称加密算法（asymmetric cryptographic algorithm）又名“公开密钥加密算法”。
    非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行 加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这 种算法叫作非对称加密算法。非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙 方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。另一方面，甲方可以使用自己的私密钥对机密信 息进行加密后再发送给乙方；乙方再用甲方的公钥对加密后的信息进行解密。
    非对称密码体制的特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。对称密码体制中只有一种密钥，并且是非公开的，如果要解密就得让对方知道密钥。所以保证其安全性就是保证密钥的安全，而非对称密钥体制有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了。这样安全性就大了很多。
   常见非对称算法有如下几种：
   1.RSA算法
   2.DH算法
   3.DSA-Digital Signature Algorithm（数字签名算法）
   4.ECC-Elliptic Curves Cryptography（椭圆曲线密码编码学）
 加解密算法使用说明(java语言)

一、BASE64编码算法
    BASE64算法类似于URLEncoder/URLDecoder类的算法，实际上是一种转码的算法，并不是加密算法。转码后，每76个字符加一个换行符。
    BASE64的实现类比较多，简单介绍2种。
   1)JDK自带实现类
 参见示例代码Base64Test.java。
 2)bouncy castle实现类
 参见示例代码BCBase64Test.java。
二、单向加密算法
1.MD5
     message digest algorithm 5 （信息摘要算法）缩写，广泛用于加密和解密技术，常用于文件校验。不管文件多大，经过MD5后都能生成唯一的MD5值,这个值的长度都是128位，即16个字节。
   MD系列包括如下算法：
   1.md2，摘要长度128位，16个字节，已过时
   2.md4，摘要长度128位，16个字节，已过时
   3.md5，摘要长度128位，16个字节
    此外，还有一种RIPEMD算法，是Hans Dobbertin等3人在md4,md5的基础上，于1996年提出来的，顾名思义RIPEMD就是成熟md算法。算法共有4个标准128、160、 256和320，其对应输出长度分别为16字节、20字节、32字节和40字节。不过，让人难以致信的是RIPEMD的设计者们根本就没有真正设计256 和320位这2种标准，他们只是在128位和160位的基础上，修改了部分参数来达到输出为256和320位的目的。所以，256位的强度和128相当， 而320位的强度和160位相当。
   RIPEMD系列算法如下
   1.ripemd128，摘要长度128位，16个字节
   2.ripemd160，摘要长度160位，20个字节
   3.ripemd256，相当于ripemd128算法
   4.ripemd320，相当于ripemd160算法
   摘要长度越长，破解难度也就越大，安全性也就越高。
   应用代码参见示例Md5Test.java

   2.SHA
   SHA(Secure Hash Algorithm，安全散列算法），数字签名等密码学应用中重要的工具，被广泛地应用于电子商务等信息安全领域。虽然，SHA与MD5通过碰撞法都被破 解了，但是SHA仍然是公认的安全加密算法，较之MD5更为安全。SHA系列算法要求输入消息的长度不超过264位，1G=230位，最大长度为 234G，实际应用中不会出现超过最大限制的数据，可以不考虑消息长度的问题。
    SHA系列算法包括如下几种：
    1.SHA1/SHA，摘要长度160位，20个字节
    2.SHA256，摘要长度256位，32个字节
    3.SHA384，摘要长度384位，48个字节
    4.SHA512，摘要长度512位，64个字节
    摘要长度越长，破解难度也就越大，安全性也就越高。
    应用代码参见示例ShaTest.java。
    3.HMAC  HMAC(Hash Message Authentication Code)，散列消息鉴别码，基于密钥的Hash算法的认证协议，也叫MAC算法。消息鉴别码实现鉴别的原理是，用公开函数和密钥产生一个固定长度的值作 为认证标识，用这个标识鉴别消息的完整性。使用一个密钥生成一个固定大小的小数据块，即摘要，并将其加入到消息中，然后传输。接收方利用与发送方共享的密 钥及摘要进行鉴别认证等。
    应用代码参见示例HmacTest.java。

    三、对称加密算法
    1.DES   DES-Data Encryption Standard,即数据加密算法。是IBM公司于1975年研究成功并公开发表的。DES算法的入口参数有三个:Key、Data、Mode。其中 Key为8个字节共64位,是DES算法的工作密钥;Data也为8个字节64位,是要被加密或被解密的数据;Mode为DES的工作方式,有两种:加密 或解密。? 　　DES算法把64位的明文输入块变为64位的密文输出块,它所使用的密钥也是64位。
    应用代码参见示例DesSingleTest.java。
2.3DES
  3DES（即Triple DES）是DES向AES过渡的加密算法，它使用3条56位的密钥对数据进行三次加密。是DES的一个更安全的变形。它以DES为基本模块，通过组合分组方法设计出分组加密算法。比起最初的DES，3DES更为安全。
   之所以称为3DES，是因为该算法加解密时使用3个密钥k1，k2，k3，操作过程如下：
   加密过程：加密（使用k1）-解密（使用k2）-加密（使用k3）
   解密过程：解密（使用k3）-加密（使用k2）-解密（使用k1）
  加密/解密均操作了3次，相当于进行了3次DES加密/解密，所以叫做3DES，当然其需要的运算时间要比DES算法多。
   实际使用时，密钥长度需要为24个字节，这24个字节会被分为3个8字节段，k1，k2，k3均从8字节段中取56位得出。
   应用代码参见示例DesedeTest.java。
3.AES
    AES是美国国家标准技术研究所NIST旨在取代DES的21世纪的加密标准。AES是一个标准，并不是具体的加密算法。
　 　AES标准的基本要求是，采用对称分组密码体制，密钥长度的最少支持为128、192、256，分组长度128位，算法应易于各种硬件和软件实现。 1998年NIST开始AES第一轮分析、测试和征集，共产生了15个候选算法。1999年3月完成了第二轮AES2的分析、测试。2000年10月2日 美国政府正式宣布选中比利时密码学家Joan Daemen 和 Vincent Rijmen 提出的一种密码算法RIJNDAEL 作为AES的标准算法，也叫RIJNDAEL算法。该算法支持密钥长度为128位。
    应用代码参见示例AesTest.java。
4.Twofish
    Twofish?则是counterpane?公司向NIST提交的一种满足AES要求的加密算法。Twofish采用128位数据块 (128?bits?block)，128-192-256-bit?可变长度密钥。这中算法比DES和RIJNDAEL算法速度更快，灵活性更高。
    应用代码参见示例TwoFishTest.java。
5.Blowfish
  Blowfish是1993年布鲁斯·施奈尔(Bruce Schneier)开发的对称密钥区块加密算法，区块长为64位，密钥为1至448位的可变长度。与DES等算法相比，其处理速度较快。因为其无须授权即 可使用，作为一种自由授权的加密方式在SSH、文件加密软件等被广泛地使用。
   blowfish算法的密钥位长度位数必须为8的整数倍。
   应用代码参见示例BlowFishTest.java。
6.RC2
  RC2是由著名密码学家Ron Rivest设计的一种传统对称分组加密算法，它可作为DES算法的建议替代算法。它的输入和输出都是64比特。密钥的长度是从1字节到128字节可变。
   应用代码参见示例RC2Test.java、RC2JavaTest.java。
7.RC4
   RC4算法是一种在电子信息领域加密的技术手段，用于无线通信网络。RC4加密算法是大名鼎鼎的RSA三人组中的头号人物Ron Rivest在1987年设计的密钥长度可变的流加密算法。该算法的速度可以达到DES加密的10倍左右。密钥长度1-256字节。
  RC4广泛应用在安全套接字层（SSL）（用来保护网络上传输的数据）和WEP（无线网络数据保护）上。以色列魏茨曼研究所和美国思科公司的研究者发现， 在使用“有线等效保密规则”（WEP）的无线网络中，在特定情况下，人们可以逆转RC4算法的加密过程，获取密钥，从而将己加密的信息解密。实现这一过程 并不复杂，只需要使用一台个人电脑对加密的数据进行分析，经过几个小时的时间就可以破译出信息的全部内容。所以在设置无线网的密码加密方式时最好选择 WPA加密方式，提高安全性。
   应用代码参见示例RC4Test.java。
8.RC5
   RC5分组密码算法是1994由麻萨诸塞技术研究所的Ronald L. Rivest教授发明的，并由RSA实验室分析。是一种非常快速且简单的算法，由块尺寸、运算轮数和密钥长度参数化，这些参数能被调整，以满足不同的安全 需求。Bouncy Castle加密包提供块长度为32和642种方式。
     块长度：常用16，32，64位；运算轮数有效值：1-255；密钥字节长度有效值：1-255。
     应用代码参见示例RC5Test.java、RC5JavaTest.java。
9.RC6
   RC6算法是在RC5算法的基础上设计的，也是由麻萨诸塞技术研究所的Ronald L. Rivest教授设计，是根据AES标准在RC5算法的基础上实现的。因此，RC6也可以指定和RC5一样的块长度，运算轮数，密钥字节长度。
     有实验表明：
     ①从程序的执行效率来看，无论在加密还是在解密过程中，RC5算法都要比RC6算法执行效率高。因此，在一些非常注重程序执行效率，而对数据安全性要求不是非常高的情况下，应该采用RC5算法。
     ②从程序的执行时间来看，无论在加密过程还是在解密过程中，RC5算法都要比RC6算法省时。因此，在一些对程序执行时间长短要求很高，对数据安全性要求不是非常高的情况下，可以采用RC5算法。
     ③从程序的大小来看，无论在加密过程中还是在解密过程中，RC5算法都要比RC6算法更简洁。因此，在一些对程序所用空间大小要求很高，对数据安全性要求不是非常高的情况下，可以采用RC5算法。
     ④从安全性角度考虑，RC6算法是在RC5算法基础之上针对RC5算法中的漏洞，主要是循环移位的位移量并不取决于要移动次数的所有比特，通过采用引入乘 法运算来决定循环移位次数的方法，对RC5算法进行了改进，从而大大提高了RC6算法的安全性。因此，在一些对数据安全性要求很高的情况下，应该采用 RC6算法。
    应用代码参见示例RC6Test.java。
10.PBE
?    PBE—Password-based encryption（基于密码加密）。其特点在于口令由用户自己掌管，不借助任何物理媒体；由用户提供初始密码和初始盐（也可以看做是第二个密码），采 用单向加密和对称加密算法混合加密，是一种简便、安全的加密方式。需要注意的是，盐只能是64位，8个字节，不能多于或者少于64位。密码长度不限。
    应用代码参见示例PBETest.java。
11.CAST
   CAST算法是由加拿大的Carlisle Adams(Entrust Technologies)和Stafford Tavares共同设计的。尽管CAST常常被看作算法，实际上它是用于构造算法的设计过程。  
CAST设计过程的细节已经向密码学界公布了，专家们可以评论和分析它，并且必须承受全部密码分析的尝试。各种各样的研究表明CAST比DES具有更强的抗攻击能力，而且在加密和解密上要更快一些。CAST算法比典型的DES算法大约快5-6倍。
     CAST算法是分组算法，它使用64位分组作为输入。CAST算法的设计允许可变的密钥长度，变化范围在40-256位。“CAST算法”使用的迭代轮数 由设计者决定。报告已经显示一个仅仅使用8轮迭代的“CAST算法”比DES（使用16轮迭代）具有稍强一些的抗攻击能力。CAST算法已经被美国和加拿 大政府接受作为代替DES的候选算法之一。
    Bouncy Castle实现支持2种方式：
    1)Cast5，64位分组，密钥长度1-128位,应用代码参见示例CAST5Test.java。
    2)Cast6，128位分组，密钥长度1-256位,应用代码参见示例CAST6Test.java。
12.IDEA
  IDEA(International Data Encryption Algorithm)是瑞士的James Massey，Xuejia Lai等人提出的加密算法，在密码学中属于数据块加密算法(Block Cipher)类。IDEA使用长度为128bit的密钥，数据块大小为64bit。从理论上讲，IDEA属于“强”加密算法，至今还没有出现对该算法的 有效攻击算法。早在1990年，Xuejia Lai等人在EuroCrypt’90年会上提出了分组密码建议PES(Proposed Encryption Standard)。在EuroCrypt’91年会上, Xuejia Lai等人又提出了PES的修正版IPES(Improved PES)。目前IPES已经商品化，并改名为IDEA。IDEA已由瑞士的Ascom公司注册专利，以商业目的使用IDEA算法必须向该公司申请许可。
   应用代码参见示例IDEATest.java。
四、非对称加密算法
1. RSA  这种算法1978年就出现了，它是第一个既能用于数据加密也能用于数字签名的算法。它易于理解和操作，也很流行。算法的名字以发明者的名字命名：Ron Rivest, Adi Shamir 和Leonard Adleman。

这种加密算法的特点主要是密钥的变化，上文我们看到DES只有一个密钥。相当于只有一把钥匙，如果这把钥匙丢了，数据也就不安全了。RSA同时有两把钥匙，公钥与私钥。同时支持数字签名。数字签名的意义在于，对传输过来的数据进行校验。确保数据在传输工程中不被修改。
     数字签名在实际应用中需要数字证书，简单介绍下Java中数字证书的生成方法。
     1).jdk安装路径下有一个keytool的工具程序，这个工具就是用来生成数字证书的。
     2).生成私钥文件
     使用命令行，切换目录到keytool所在的文件夹，执行下面的命令
     keytool -genkey -validity 36000 -alias rsatest -keyalg RSA -keysize 1024 -storetype jks -keypass 123456 -storepass 123456 -keystore d:\log\test.jks
  其中    

-genkey表示生成密钥    

-validity指定证书有效期，这里是36000天    

-alias指定别名，这里是rsatest
-keyalg指定算法，这里是RSA
-keysize 指定生成的密钥长度，这里是1024
-storetype 指定私钥文件的格式，这里是常用的jks格式，如果不指定，则默认为keystore格式
-keypass指定私钥的访问密码，这里是123456
-storepass指定私钥文件的访问密码，这里是123456   

-keystore指定存储位置，这里是d:\log\test.jks
     3).导出公钥证书    
     执行下面的命令：
     keytool -export -keystore d:\log\test.jks -alias rsatest -storepass 123456 -file d:\log\test.cer -rfc
     其中   

-export指定为导出操作  

-keystore指定keystore文件    

-alias指定导出keystore文件中的别名
-storepass指定私钥访问密码，这里是123456    

-file指向导出路径    

-rfc以文本格式输出，也就是以BASE64编码输出    

生成了数字证书文件，就可以通过证书文件进行签名了。
应用代码参见示例RsaTest.java。
     4).CA认证
     我们自己导出的公钥证书只能作为测试用，如果要求在互联网上使用，则可以使用特殊手段伪造同样的证书，这样是不安全的，所以如果有一个被普遍信任的机构再对我们的证书进行一次签名，使得我们的证书无法伪造，就会比较安全。CA机构就是要解决这个问题的。
     CA机构，又称为证书授证(Certificate Authority)中心，作为电子商务交易中受信任的第三方，相当于公证人的角色。它承担公钥体系中公钥的合法性检验的责任。CA机构使用它的证书（又 称为根证书）对用户提交的证书进行签名，使得攻击者不能伪造和篡改用户证书。一般各种浏览器都会安装主流CA机构的根证书，只要是由这些机构认证过的证书 都被浏览器信任；否则，浏览器将给出警告。如果浏览器没有某个CA机构的根证书，可以由用户安装。（网上订过火车票的同事应该已经知道如何安装）
     申请CA机构的官方认证，需要提交证书申请文件，使用如下命令生成
     keytool -certreq -alias rsatest -file d:\log\test.csr -keystore d:\log\test.jks -storepass 123456 –v
     该命令会产生test.csr证书申请文件，把该文件提交给CA机构，就可以得到官方认证的公钥证书，多为p7b格式。
     应用代码参见示例RsaTest.java。
2.DH
Diffie-Hellman算法(D-H算法)，密钥一致协议。是由公开密钥密码体制的奠基人Diffie和Hellman所提出的一种思想。DH算法综合使用了对称加密和非对称加密技术。DH算法的交互流程如下：
1. 甲方构建密钥对儿，将公钥公布给乙方，将私钥保留；双方约定数据加密算法；乙方通过甲方公钥构建密钥对儿，将公钥公布给甲方，将私钥保留。?     2.甲方使用私钥、乙方公钥、约定数据加密算法构建本地密钥，然后通过本地密钥加密数据，发送给乙方加密后的数据；乙方使用私钥、甲方公钥、约定数据加密 算法构建本地密钥，然后通过本地密钥对数据解密。?     3.乙方使用私钥、甲方公钥、约定数据加密算法构建本地密钥，然后通过本地密钥加密数据，发送给甲方加密后的数据；甲方使用私钥、乙方公钥、约定数据加密 算法构建本地密钥，然后通过本地密钥对数据解密。
应用代码参见示例DhTest.java。

3.DSA  
DSA-Digital Signature Algorithm 是Schnorr和ElGamal签名算法的变种，被美国NIST作为DSS(DigitalSignature Standard)。简单的说，这是一种更高级的验证方式，用作数字签名。不单单只有公钥、私钥，还有数字签名。私钥加密生成数字签名，公钥验证数据及签 名。如果数据和签名不匹配则认为验证失败！数字签名的作用就是校验数据在传输过程中不被修改。
DSA算法也可以使用文件形式的数字证书，制作方法同RSA证书，如：
keytool -genkey -validity 36000 -alias dsatest -keyalg DSA -keysize 1024 -storetype jks -keypass 123456 -storepass 123456 -keystore d:\log\dsatest.jks
导出证书：
keytool -export -keystore d:\log\dsatest.jks -alias dsatest -storepass 123456 -file d:\log\dsatest.cer -rfc
应用代码参见示例DsaTest.java。
4.ECC   ECC(Elliptic Curves Cryptography)，椭圆曲线密码编码学，是目前已知的公钥体制中，对每比特所提供加密强度最高的一种体制。在软件注册保护方面起到很大的作用，一般的序列号通常由该算法产生。
ECC算法在jdk1.5后加入支持，目前仅仅只能完成密钥的生成与解析。 如果想要获得ECC算法实现，需要调用硬件完成加密/解密（ECC算法相当耗费资源，如果单纯使用CPU进行加密/解密，效率低下）。涉及到Java Card领域，PKCS#11。

附：安装bouncy castle算法包
  在java中实现很多加密算法的时候都需要使用到bouncy castle的算法包，可以使用如下代码添加该包提供的功能：
 Security.addProvider(new BouncyCastleProvider());
    为了方便使用，该算法包可以手工配置到jre环境中，简单介绍下配置方法。
 1.获取算法包
      bouncy castle官网：，根据所使用的jdk,到该网站获取对应版本的jar包。我用的是jdk1.4,用的是bcprov-jdk14-139.jar。
 2.把bcprov-jdk14-139.jar复制到jdk安装目录\jre\lib\ext目录下

 3.编辑jdk安装目录\jre\lib\security下java.security文件
  使用编辑工具打开java.security文件后找到如下片段：    
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvide
在最后声明security.provider的一行代码之后再添加一行：
rsecurity.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
6，是由前面一行的数值加1得到的；org.bouncycastle.jce.provider.BouncyCastleProvider就是bouncy castle的算法提供者，jdk在前5个算法提供者中都找不到相应的算法时就会到该类中查找。

4.可以使用bouncy castle算法包了。

小知识之加密算法:

数据加密的基本过程就是对原来为明文的文件或数据按某种算法进行处理，使其成为不可读的一段代码，通常称为“密文”，使其只能在输入相应的密钥之后才能显示出本来内 容，通过这样的途径来达到保护数据不被非法人窃取、阅读的目的。 该过程的逆过程为解密，即将该编码信息转化为其原来数据的过程。

-----------------------------------------------------------------------

 

加密技术及流行加密算法

深入浅出谈加密
加密技术已经渗透进了整个信息时代，任何人都不可避免地要接触到——即使你根本不知道“加密”是什么。银行卡、登录计算机的口令、电子邮件的账号密码……无一例外地跟加密技术紧紧联系在一起。
任何一个安全专家提起如今信息技术的安全保护措施，都不可避免要涉及一个词：加密（encrypt）。的确，纵观当今信息世界，加密离我们并不遥远，从小小的个人密码，到重要机密文件，无一不是经过加密后的产物。
许多人一提起“加密”，都会有一种畏惧心理，以为加密技术绝对是“新手勿近”的尖端科技。其实不然，加密实际上一直陪伴在你一生的成长之中，回忆一下小时候很多人都玩过的智力游戏：007收到遇害同事的字条，上面写着4FEFKKILJK81IP，根据事先约定，已知C=3、Q＝H，问该同事要传递什么信息给007？如果把这道题目放到信息技术领域来看待，就是一条经过简单替换字符算法加密的字符串，它把原始字符改为使用相对应的数字排序来替代，从而产生了一组“没有意义”的字符组合，但是因为我们知道C＝3等若干条件，所以稍加排序即可得到这样的句子：Do not trust Hary，这个过程也被称为“解密”（decrypt）。
有些读者也许会不屑一顾，就这么简单的游戏也算加密？别忘了，我们是在已经知道“C=3”的前提下完成“解密”的，换句话说，也就是已经知道了“算法”，否则光凭以上一组不知所云的字符串，谁能解开其中的秘密？

加密和解密
“就不让你直接看到信息”——将与之相似的思路加以扩充，便成了“加密”的来由；而拓展“我偏要看到你不想让我看的信息”的思想，则发展出了“解密”技术。加密和解密从诞生之日起，就是一对不可分割的难兄难弟。
加密作为保障数据安全的一种方式，很早就出现在人类的信息传递中，从远古时代开始，人们就已经在采用一种如今称为“编码”（Code）的方法用于保护文字信息。最早影响全世界的加密技术诞生于战争年代，由德国人发明，用于传递情报信息；而最早影响全世界的解密技术，也诞生于战争年代，由英美人开发出来用于破译德国人的情报信息。正是战争让加解密技术不断改进发展，直到现在，加密技术仍然在为信息时代的数据安全服务。
说了这么多，也该为加密技术做一个较为准确而科学的概念了，所谓“加密”，就是对原内容为明文的文件或数据按某种算法进行处理，使其成为不可读的代码，经过这样处理的数据通常称为“密文”，密文只能在经过相对应的反向算法处理后才能恢复原来的内容，通过这样的途径来达到保护数据不被非法窃取、阅读的目的，而将该编码信息转化为其原来数据的过程，就是“解密”。
无论哪一个国家，都会有专家专注于加密技术的研究，因此也就出现了形形色色的加密算法，这些加密算法按照生物界“弱肉强食”的定律发展并完善着。其中，强度高（不容易被破解）的算法得以保留和继续发展，强度低的算法最终被时间淘汰。除了一些公开的加密算法之外，也存在着一部分未公开的私人加密算法。通常我们提及加密技术时所说的“MD5加密”、“SHA-1加密”、“RSA加密”等，其实就是在说它们所采用的算法。

算法：关键的抉择
“我想要葡萄，还想要橙子，可是我只能选择其中一样，我该选哪个？”如果要为自己的数据加密，我们就不得不面对这样一个选择，因为世界上的算法不止一个，究竟什么算法才是最适合的呢？于是，我们逐渐陷入一个选择的泥潭中。其实，在选择使用哪种算法作为你的加密基础前，如果能对各种常见算法的原理有个大概的了解，相信你就不会感到那么迷茫了。

基于“消息摘要”的算法
“消息摘要”（Message Digest）是一种能产生特殊输出格式的算法，这种加密算法的特点是：无论用户输入什么长度的原始数据，经过计算后输出的密文都是固定长度的，这种算法的原理是根据一定的运算规则对原数据进行某种形式的提取，这种提取就是“摘要”，被“摘要”的数据内容与原数据有密切联系，只要原数据稍有改变，输出的“摘要”便完全不同，因此，基于这种原理的算法便能对数据完整性提供较为健全的保障。但是，由于输出的密文是提取原数据经过处理的定长值，所以它已经不能还原为原数据，即消息摘要算法是“不可逆”的，理论上无法通过反向运算取得原数据内容，因此它通常只能被用来做数据完整性验证，而不能作为原数据内容的加密方案使用，否则谁也无法还原。尽管如此，“消息摘要”算法还是为密码学提供了健全的防御体系，因为连专家也无法根据拦截到的密文还原出原来的内容。
如今常用的“消息摘要”算法经历了多年验证发展而保留下来的算法已经不多，这其中包括MD2、MD4、MD5、SHA、SHA-1/256/383/512等，其中最广泛应用的是基于MD4发展而来的MD5算法。
MD5算法
MD5算法的全称是“消息摘要算法5”（Message-Digest Algorithm version.5），它是当前公认的强度最高的加密算法。出现在MD5之前的是MD2和MD4，虽然这三者的算法结构多少有点相似，但是由于MD2诞生于8位计算的时代，因此它的设计与后来出现的MD4、MD5完全不同，因此不能进行简单的替代。然而，无论是MD2、MD4还是MD5，它们都是在获得一个随机长度信息的基础上产生一个128位信息摘要的算法。
MD2算法是Rivest在1989年开发的，它很慢（因为是为8位机器设计的），但相当安全。在这个算法中，首先要对信息进行数据补位，使信息的字节长度是16的倍数。然后，以一个16位的检验和追加到信息末尾，并且根据这个新产生的信息计算出散列值（Hash），最终运算结果即为类似于“d41d8cd98f00b204e9800998ecf8427e”的摘要，而且这个值是惟一的。
为了加强算法的安全性，Rivest在1990年又开发出MD4算法。MD4算法同样需要填补信息以确保信息的字节长度加上448后能被512整除（信息字节长度除以512的余数为448）。然后，一个以64位二进制表示的信息的最初长度被添加进来。

然而，MD4存在一个严重漏洞，那就是“冲突”（Collisions）。“冲突”是所有基于“摘要”的算法都要面对的最大问题，由于它们是根据“不完整”的数据内容产生的密文，如果运算过程存在瑕疵，就会在处理某些不同数据时产生相同的摘要，这带来的后果可是致命的。因为“摘要”算法的原则是原数据不可还原，因此验证的过程并不同于简单加密运算里的“数据还原匹配”，验证端同样要根据原数据运算得到的摘要作为凭据与客户端发来的摘要进行匹配检验，如果两段字符串完全相同，即视为验证通过。这是在“摘要算法”理论上“不可逆且惟一”的基础上采用的安全检验方法，验证方可以不需要索取原数据，而只要拥有一个有效的摘要即可完成对客户端的身份确认，大大减少了原数据被入侵者截获的几率。
但是这样的验证方式就产生了一个“看似不可能”的缺陷：假如入侵者能伪造出一段数据，使之能在通过“摘要”计算后产生的摘要与真正的原数据产生的摘要一样，那么入侵者便能冒充原数据持有者通过身份验证。这在理论上是不可能的，然而现实总是不会让人那么愉快，由于算法不可避免地出现了漏洞，使得这个设想成为了事实，这就是“冲突”的来源：某两个或多个数据产生的摘要出现了完全雷同的现象，使得用户能在输入了即使不是原数据的密码后能顺利通过验证，因为身份检验程序发现原本储存的用户信息的签名数据与接收到的数据的运算结果完全一致，于是认为请求方为合法用户，就给予通过了。这种运算结果相同的现象，就是“冲突”。

“冲突”会造成非常危险的后果，因此MD4被无情地抛弃了，取而代之的是在MD4基础上加强了算法的MD5，它在MD4的基础上增加了“安全带”（Safety Belts）的概念，虽然MD5比MD4稍微慢一些，但却大大减小了冲突的发生率，虽然很早以前就有专家发现MD5算法在专门用于寻找“冲突”的机器上平均每24天就会产生一个“冲突”，但是对于一般应用来说，这种几率非常低微，因此MD5至今仍然是最强健的加密算法之一。
有读者也许会问，既然MD5是不可逆的，那么网络上存在的那些“MD5密码破解工具”又是什么回事？其实，那并不是破解，至今MD5还没能被完全破解过，虽然曾经有过一篇报道称中国的一个教授破解了MD5加密算法，但是后来这个结论又被推翻了。网络上流传的那些工具纯粹是依赖于“运气＋机器性能＋耐心”的产品而已，它们的原理是“穷举”，即程序在一定的数据范围内产生一系列数据组合进行MD5运算，再把运算结果与获取的摘要进行比较，如果两者相同，就被定义为“破解”了。这只是一种穷举法而已，实际意义不大，要知道在不产生冲突的前提下生成一个与原数据完全相同的字符串要有多少运气的成分，更何况它还完全依赖于你的机器性能，如果对方密码简单如123456这样的形式，我们还可能侥幸在1分钟～1天内运算出来，但是如果对方密码是0e1WeTru9t@MD5这样的组合呢？MD5的高强度使得它如此难以破解，因此成为大众首选，许多入侵者在辛苦取得目标网站数据库后，一看password字段都是0ca175b9c0f726a831d895e269332461的形式，第一反应都会是“晕倒！又白干了！”
对称/非对称密钥加密算法
由于“摘要”算法加密的数据仅仅能作为一种身份验证的凭据使用，如果我们要对整个文档数据进行加密，就不能采用这种“不可逆”的算法了。“密钥”算法（Key Encoding）的概念因此而被提出，与开头提到的智力题类似，此类算法通过一个被称为“密钥”的凭据进行数据加密处理，接收方通过加密时使用的“密钥”字符串进行解密，即双方持有的“密码”相同（对称）。如果接收方不能提供正确的“密钥”，解密出来的就不是原来的数据了。
以上是“对称密钥”的概念，那么“非对称密钥”又该怎么理解呢？有人用邮箱作为比喻，任何人都可以从邮箱的信封入口塞进信件，但是取信的权力却仅仅在于持有邮箱钥匙的人的手上。这个众人皆知的信封入口就是“公钥”（Public Key），而你持有的邮箱钥匙就是“私钥”（Private Key）。这种算法规定，对方给你发送数据前，可以用“公钥”加密后再发给你，但是这个“公钥”也无法解开它自己加密的数据，即加密过程是单向的，这样即使数据被途中拦截，入侵者也无法对其进行破解，能还原数据内容的只有“私钥”的持有者，这就是“非对称密钥”加密算法，也称为“公共密钥算法”。
你也许会想，这两种形式加密出来的数据如果稍加耐心进行分析，一定能找到变化规律从而直接破解。这个想法没错，但是专家早就思考过这个可能性了，因此这种算法虽然是采用某个字符串作为凭据进行加密操作的，可是它可能把凭据拆分为多个不同的“子段”并进行多次运算，最终的结果就是让你难以发现变化的规律，破解也就难上加难。
基于“对称密钥”的加密算法主要有DES、TripleDES、RC2、RC4、RC5和Blowfish等；基于“非对称密钥”的加密算法主要有RSA、Diffie-Hellman等。
对称密钥：DES、TripleDES算法
美国国家标准局在1973年开始研究除国防部以外其他部门的计算机系统的数据加密标准，最终选用了IBM公司设计的方案作为非机密数据的正式数据加密标准（DES即Data Encryption Standard）。DES算法从诞生开始，就被各个领域广泛采用，包括ATM柜员机、POS系统、收费站等，DES以它高强度的保密性能为大众服务，那么，它是如何工作的呢？
DES算法把64位的明文输入块变为64位的密文输出块，它所使用的密钥也是64位。首先，DES把输入的64位数据块按位重新组合，并把输出分为L0、R0两部分，每部分各长32位，并进行前后置换，最终由L0输出左32位，R0输出右32位，根据这个法则经过16次迭代运算后，得到L16、R16，将此作为输入，进行与初始置换相反的逆置换，即得到密文输出。
DES算法具有极高的安全性，到目前为止，除了用穷举搜索法对DES算法进行攻击外，还没有发现更有效的办法，而56位长密钥的穷举空间为256，这意味着如果一台计算机的速度是每秒种检测100万个密钥，那么它搜索完全部密钥就需要将近2285年的时间，因此DES算法是一种很可靠的加密方法。
对称密钥：RC算法
RC系列算法是大名鼎鼎的RSA三人组设计的密钥长度可变的流加密算法，其中最流行的是RC4算法，RC系列算法可以使用2048位的密钥，该算法的速度可以达到DES加密的10倍左右。
RC4算法的原理是“搅乱”， 它包括初始化算法和伪随机子密码生成算法两大部分，在初始化的过程中，密钥的主要功能是将一个256字节的初始数簇进行随机搅乱，不同的数簇在经过伪随机子密码生成算法的处理后可以得到不同的子密钥序列，将得到的子密钥序列和明文进行异或运算（XOR）后，得到密文。
由于RC4算法加密采用的是异或方式，所以，一旦子密钥序列出现了重复，密文就有可能被破解，但是目前还没有发现密钥长度达到128位的RC4有重复的可能性，所以，RC4也是目前最安全的加密算法之一。
非对称密钥：RSA算法
RSA算法是目前最流行的公钥密码算法，它使用长度可以变化的密钥。RSA是第一个既能用于数据加密也能用于数字签名的算法。
RSA算法的原理如下：
1.随机选择两个大质数p和q，p不等于q，计算N=pq；
2.选择一个大于1小于N的自然数e，e必须与(p-1)×(q-1)互素。
3.用公式计算出d：d×e = 1 (mod (p-1)×(q-1)) 。
4.销毁p和q。
最终得到的N和e就是“公钥”，d就是“私钥”，发送方使用N去加密数据，接收方只有使用d才能解开数据内容。
RSA的安全性依赖于大数分解，小于1024位的N已经被证明是不安全的，而且由于RSA算法进行的都是大数计算，使得RSA最快的情况也比DES慢上好几倍，这也是RSA最大的缺陷，因此它通常只能用于加密少量数据或者加密密钥。需要注意的是，RSA算法的安全性只是一种计算安全性，绝不是无条件的安全性，这是由它的理论基础决定的。因此，在实现RSA算法的过程中，每一步都应尽量从安全性方面考虑。

小密码，大学问
随着信息化走进千家万户，人们越来越关注自己的数据安全，而数据安全除了在攻防体系上必须有所保障以外，关键的一点就是要对其进行强度够高的加密，进一步减小数据被盗窃后的损失。这一观点早已在网络论坛的发展中得到了证实，早期的论坛数据库都是未经过加密处理就直接保存的，在这个前提下，只要入侵者拿到了数据库，就等于拿到了整个论坛，因为密码字段是明文形式的。有些重要的网站甚至使用一些后台没有提供数据加密方案的程序做站点，这是非常不明智的。
确定了加密方案后，有些人就自己写算法进行数据加密，殊不知这也算产生了安全隐患，通常个人无法写出高强度的加密算法，入侵者如果稍加分析便能破译内容，你的辛苦也就付之东流。相反，如果采用在国际得到安全认证的流行加密方案，数据安全反而提高了，何乐而不为？

-------------------

https://blog.csdn.net/cut001/article/details/53189645 （ RSA公钥，私钥和数字签名，这样最好理解）

-----------------

 

RC4加密已不再安全，被破解的效率极高

 

安全研究人员称，现在世界上近三分之一的HTTPS加密连接可被破解，并且效率极高。这种针对RC4加密的破解技术，同样也可以用来破解WiFi数据包。

FreeBuf百科：RC4加密算法*

RC4（Rivest密码4）由RSA Security的Ron Rivest在1987年设计，因为其速度和简单性，这种加密算法已经成为使用最为广泛的流密码。它被用于常用协议中，包括有线等效保密（WEP），用于无线网络的安全算法，以及HTTPS的安全套接字层（SSL）和传输层安全（TLS）协议；事实上，在所有TLS流量中，约有50%的流量目前在使用RC4算法来保护。

破解RC4已成熟

研究人员很早前就发现可以利用RC4中的统计偏差，导致可对加密信息中的一些伪随机字节能进行猜测。在2013年，科学家利用这个漏洞设计了一次攻击实验：他们在2000小时内猜出一个基础身份认证cookie中包含的字符。后来技术改进后，研究人员只需约75小时猜解就能得到94%的准确率。

另外，针对WPA-TKIP网络的猜解攻击大概只需要花上1个小时的时间。研究人员表示，现在RC4加密已经不安全了，建议完全停止使用。

“我们研究出的方法能大大减少破解的执行时间，这种攻击效率的提升让我们感到很不安。我们觉得还有提升的空间，也能实现更高效的算法。我们希望将来会有更好的通讯加密技术。

Youtube原地址：https://youtu.be/d8MtmKrXlKQ

技术细节浅析

攻击者可以通过中间人手段，监控目标与Https网站之间的会话连接，或者监控WPA-TKIP保护的网络。在第一种情况下，攻击者向另一个非Https网站注入了Javascript代码，会诱使访问它的目标计算机迅速多次传输加密身份认证的cookie。通过分析约9*2^{27个加密的cookie，攻击者可以将猜测准确率提升至94%。期间，攻击者需要让目标每秒发送4450个请求，在经过75小时后（特殊情况下只需52小时），就可以完成猜解攻击。在两年前发生的一次攻击中，研究人员需要12*2}30个cookie加密来推断实际内容，期间每秒产生了1700个请求。

新型针对WPA-TKIP的攻击只需要1个小时，攻击者可以任意注入、解密数据包。

这项技术不仅可以解密cookie和Wifi数据包，其他高速传输的加密数据流也有可能被解密。技术是通过向加密payload中注入数据，如每个认证cookie或者Wifi数据包中的标准头部。攻击者会通过组合所有可能的值，通过使用统计偏差找出最有可能的组合。

加密保护和思考

目前攻击Https保护的网站理论上只需要75小时，但鉴于推广应用技术的难度，研究人员决定只是发出警示表明RC4并不是一个安全的解决方案。工程师们需要现在就采取行动拒绝继续使用这种加密，现如今https网站中大约有30%的使用的是RC4加密，比2013年下降了约一半。

*参考来源：arstechnica

--------------

Once-theoretical crypto attack against HTTPS now verges on practicality

Certain types of Wi-Fi cypto also threatened by technique attacking RC4 cipher.

7/16/2015

Almost a third of the world's encrypted Web connections can be cracked using an exploit that's growing increasingly practical, computer scientists warned Wednesday. They said the attack technique on a cryptographic cipher known as RC4 can also be used to break into wireless networks protected by the Wi-Fi Protected Access Temporal Key Integrity Protocol.

Further Reading

Two new attacks on SSL decrypt authentication cookies

Researchers have long known statistical biases in RC4 make it possible for attackers to predict some of the pseudo-random bytes the cipher uses to encode messages. In 2013, a team of scientists devised an attack exploiting the weakness that required about 2,000 hours to correctly guess the characters contained in a typical authentication cookie. Using refinements, a separate team of researchers is now able to carry out the same feat in about 75 hours with a 94 percent accuracy. A similar attack against WPA-TKIP networks takes about an hour to succeed. The researchers said the only reliable countermeasure is to stop using RC4 altogether.

“Very worrisome”

"Our work significantly reduces the execution time of performing an attack, and we consider this improvement very worrisome," the researchers wrote in a blog post. "Considering there are still biases which are unused, that more efficient algorithms can be implemented, and better traffic generation techniques can be explored, we expect further improvements in the future."

The attack could be exploited by attackers with the ability to monitor the connection between a target and an HTTPS-protected website or WPA-TKIP-protected network. In the case of an HTTPS-protected website, the attacker uses a separate non-HTTPS-protected website to inject JavaScript code that induces the targeted computer to repeatedly transmit the encrypted authentication cookie in rapid succession. By observing roughly 9*2²⁷ encryptions of the cookie, the attacker can guess the contents with 94 percent accuracy. With the ability to make the target transmit 4,450 Web requests per second, the attack takes about 75 hours, although in some cases, the time required can be shaved down to 52 hours. In the attack from two years ago, researchers required 12*2³⁰ encryptions of a cookie to deduce its contents and could generate only about 1,700 requests per second.

The new attack against WPA-TKIP requires an hour to execute, and allows an attacker to inject and decrypt arbitrary packets.

The RC4 NOMORE Attack: Demonstration in Practice

The technique can be used not only to decrypt cookies and Wi-Fi packets, but any type plaintext that is transmitted frequently in the encrypted stream. The technique works by injecting data values that are already known to exist inside the encrypted payload, such as the standard headers that exist in every authentication cookie or Wi-Fi packet. The attack then cycles through every possible combination of characters for the unknown values and uses the statistical biases to figure out which combinations are most likely.

For now, the attack against HTTPS-protected websites remains largely theoretical given the required 75 hours. But given how hard it is to collectively retire widely used technologies, the research should serve as a stern warning that RC4 isn't a safe long-term solution, and that engineers need to act now to ween their wares and users off of the cipher. An estimated 30 percent of HTTPS sessions rely on RC4, down from about half in 2013.

"We consider it surprising this is possible using only known biases, and expect these types of attacks to further improve in the future," the researchers wrote in a research paper scheduled to be presented at next month's 24th Usenix Security Symposium. "Based on these results, we strongly urge people to stop using RC4."

from https://arstechnica.com/information-technology/2015/07/once-theoretical-crypto-attack-against-https-now-verges-on-practicality/

----------------- 

http://www.rc4nomore.com/

http://www.rc4nomore.com/vanhoef-usenix2015.pdf

------------------

【译】TLS中的RC4被攻破了，现在该怎么办？ 

原文链接：https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
原文发表时间：2013.3.19

一段时间以来，RC4都被认为是有问题的，但是直到不久前才有利用其弱点的方法。在2011年BEAST被披露后，我们建议使用RC4算法以避免TLS1.0及更早版本中使用的CBC模式密码套件的弱点。这导致使用RC4的比例大幅上升，有说法称其占据了大约50%。

上周，一组研究人员（Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt）发布了一种针对RC4攻击的有效改进，发现了新的弱点和新的利用方法。Matthew Green在他的博客上做了很好的总结，这里是新问题发布时的幻灯片。

目前，这种攻击尚未能实用，因为它需要上百万甚至上亿条使用不同密钥对相同数据进行的加密结果。浏览器需要与服务端建立多个链接才能给攻击者传递足够的数据。一种可能的利用路径是以某种方法使浏览器建立起大量的连接，同时中间人观察并记录传递的信息。

现在我们还是安全的，但是这给研究人员提升RC4攻击方法带来了很大的刺激，这也意味着我们必须要迅速行动起来。

我们(SSL Labs)将会做什么？

• 开始对我们的用户警告RC4的弱点。 RC4已经确认被攻破，当前在TLS中使用已不安全。但是困难在于，对于用户基数特别大的站点来讲，无法100%安全的替换RC4算法。我们现在除了接受它之外别无选择，无论怎么设置，一些用户仍将处于风险之中。
• 如果苹果公司实现了1/n-1 record splitting在他们的协议栈中（唯一没有实现的主流刘浏览器厂商），我们可以认为BEAST已经在客户端有效的缓解了，我们将建议用户使用非RC4的CBC密码套件。 更新：苹果在2013年10月发布的OS X Mavericks中实现了BEAST缓解措施。这意味着BEAST可以被认为得到了有效的缓解。要想了解更多信息，请参看本博文。
• 开始建议使用GCM模式的密码套件。浏览器将毫无疑问的加快对TLS 1.2和GCM密码套件提供支持，站点管理员将因此而收益。
• 更新 “SSL/TLS部署最佳实践”。
• 在不久的将来，更新评级算法，将RC4弱点纳入考量。

建议

SSL/TLS库开发者

• 加强你的协议栈对Lucky 13攻击的防御能力。（译者注：Lucky 13也是一种针对CBC模式密码套件的攻击，2013年2月发布，不过目前各大主流SSL库都已经修复了该问题。PS：漏洞太TM多了）
• 尽快提供对TLS 1.2和GCM模式密码套件的支持。

浏览器厂商

• 尽快提供对TLS 1.2和GCM模式密码套件的支持。
• 尽快实现1/n-1 record splitting以使得CBC模式密码套件在TLS1.0和更早版本中也是安全的。据我们所了解，苹果是唯一尚未对浏览器发布补丁的厂商，无论是OS X还是IOS。（2013年10月发布了）

系统管理员

• 禁用TLS压缩。这种攻击类似于最近的RC4攻击，只不过可实用。（译者注：另外一种针对SSL/TLS的攻击，利用的压缩算法的机制进行。）
• 尽快提供对TLS 1.2和GCM模式密码套件的支持。

TLS工作组

• 恢复TLS中算法的灵活性和多样性。现在AES GCM密码套件是TLS中保证安全的唯一选择，但是我们不应该一直这样。
• 考虑引入新的流密码算法。如果只有一种密码算法可选，是无法提供算法灵活性的。
• 考虑改变CBC的实现，以便解决timing问题（译者注：就是CBC模式算法漏洞产生的根源）。

应用开发者

• 强化会话管理，以提供可靠的和频繁变换的会话cookie，以增加攻击者所需要的时间和请求数量。近年来这种攻击有个趋势：需要攻击者以某种方式控制TLS连接的客户端。大部分这种攻击集中在提取信息中的一小段，比较典型的就是认证集。会话cookie现在是最为热门的目标。既然攻击是否顺利进行取决于需要多少请求，频繁的变换会话cookie是一个很好的深度防御措施。

---------------------------

RC4 is kind of broken in TLS

Listen, if you’re using RC4 as your primary ciphersuite in SSL/TLS, now would be a great time to stop. Ok, thanks, are we all on the same page?

No?

I guess we need to talk about this a bit more. You see, these slides have been making the rounds since this morning. Unfortunately, they contain a long presentation aimed at cryptographers, and nobody much seems to understand the real result that’s buried around slide 306 (!). I’d like to help.

Here’s the short summary:

According to AlFardan, Bernstein, Paterson, Poettering and Schuldt (a team from Royal Holloway, Eindhoven and UIC) the RC4 ciphersuite used in SSL/TLS is broken. If you choose to use it — as do a ridiculous number of major sites, including Google — then it may be possible for a dedicated attacker to recover your authentication cookies. The current attack is just on the edge of feasibility, and could probably be improved for specific applications.

This is bad and needs to change soon.

In the rest of this post I’ll cover the details in the usual ‘fun’ question-and-answer format I save for these kinds of attacks.

What is RC4 and why should I care?

RC4 is a fast stream cipher invented in 1987 by Ron Rivest. If you like details, you can see this old post of mine for a longwinded discussion of RC4’s history and flaws. Or you can take my word: RC4 is old and crummy.

Despite its age and crumminess, RC4 has become an extremely popular ciphersuite for SSL/TLS connections — to the point where it accounts for something absurd like half of all TLS traffic. There are essentially two reasons for this:

1. RC4 does not require padding or IVs, which means it’s immune to recent TLS attacks like BEAST and Lucky13. Many admins have recommended it as the solution to these threats.
2. RC4 is pretty fast. Faster encryption means less computation and therefore lower hardware requirements for big service providers like Google.

So what’s wrong with RC4?

Like all stream ciphers, RC4 takes a short (e.g., 128-bit) key and stretches it into a long string of pseudo-random bytes. These bytes are XORed with the message you want to encrypt, resulting in what should be a pretty opaque (and random-looking) ciphertext.

The problem with RC4 is that the above statement is not quite true. The bytes come out of the RC4 aren’t quite random looking — they have small biases. A few of these biases have been known for years, but weren’t considered useful. However, recent academic work has uncovered many small but significant additional biases running throughout the first 256 bytes of RC4 output. This new work has systematically identified many more.

At first blush this doesn’t seem like a big deal. Cryptographically, however, it’s a disaster. If I encrypt the same message (plaintext) with many different RC4 keys, then I should get a bunch of totally random looking ciphertexts. But these tiny biases mean that they won’t be random — a statistical analysis of different positions of the ciphertext will show that some values occur more often.

By getting many different encryptions of the same message — under different keys — I can tally up these small deviations from random and thus figure out what was encrypted.

If you like analogies, think of it like peeking at a picture with your hands over your eyes. By peeking through your fingers you might only see a tiny sliver of the scene you’re looking at. But by repeating the observation many times, you may be able to combining those slivers and figure out what you’re looking at.

Why would someone encrypt the same message many times?

The problem here (as usual) is your browser.

You see, there are certain common elements that your browser tends to send at the beginning of every HTTP(S) connection. One of these values is a cookie — typically a fixed string that identifies you to a website. These cookies are what let you log into Gmail without typing your password every time.

If you use HTTPS (which is enforced in many sites by default), then your cookies should be safe. After all, they’ll always be sent over an encrypted connection to the website.Unfortunately, if your connection is encrypted using RC4 (as is the case with Gmail), then each time you make a fresh connection to the Gmail site, you’re sending a new encrypted copy of the same cookie. If the session is renegotiated (i.e., uses a different key) between those connections, then the attacker can build up the list of ciphertexts he needs.

To make this happen quickly, an attacker can send you a piece of Javascript that your browser will run — possibly on a non-HTTPS tab. This Javascript can then send many HTTPS requests to Google, ensuring that an eavesdropper will quickly build up thousands (or millions) of requests to analyze.

Millions of ciphertexts? Pah. This is just crypto-wankery.

It’s true that the current attack requires an enormous number of TLS connections — in the tens to hundreds of millions — which means that it’s not likely to bother you. Today. On the other hand, this is the naive version of the attack, without any special optimizations.

For example, the results given by Bernstein assume no prior plaintext knowledge. But in practice we often know a lot about the structure of an interesting plaintext like a session cookie. For one thing, they’re typically Base64 encoded — reducing the number of possibilities for each byte — and they may have some recognizable structure which can be teased out using advanced techniques.

It’s not clear what impact these specific optimizations will have, but it tends to reinforce the old maxim: attacks only get better, they never get worse. And they can get a lot better while you’re arguing about them.

So what do we do about it?

Treat this as a wakeup call. Sites (like Google) need to stop using RC4 — before these attacks become practical. History tells us that nation-state attackers are already motivated to penetrate Gmail connections. The longer we stick with RC4, the more chances we’re giving them.

In the short term we have an ugly choice: stick with RC4 and hope for the best, or move back to CBC mode ciphersuites — which many sites have avoided due to the BEAST and Lucky13 attacks.

We could probably cover ourselves a bit by changing the operation of browsers, so as to detect and block Javascript that seems clearly designed to exercise these attacks. We could also put tighter limits on the duration and lifespan of session cookies. In theory we could also drop the first few hundred bytes of each RC4 connection — something that’s a bit of a hack, and difficult to do without breaking the TLS spec.

In the longer term, we need to move towards authenticated encryption modes like the new AEAD TLS ciphersuites, which should put an end to most of these problems. The problem is that we’ll need browsers to support these modes too, and that could take ages.

In summary

I once made fun of Threatpost for sounding alarmist about SSL/TLS. After all, it’s not like we really have an alternative. But the truth is that TLS (in its design, deployment and implementation) needs some active help. We’re seeing too many attacks, and they’re far too close to practical. Something needs to give.

We live in a world where NIST is happy to give us a new hash function every few years. Maybe it’s time we put this level of effort and funding into the protocols that use these primitives? They certainly seem to need it.

from https://blog.cryptographyengineering.com/2013/03/12/attack-of-week-rc4-is-kind-of-broken-in/

-------------------------

On the Security of RC4 in TLS and WPA

13th March 2013

Introduction

This page is about the security of RC4 encryption in TLS and WPA/TKIP. For details of the Lucky 13 attack on CBC-mode encryption in TLS, click here.

The Transport Layer Security (TLS) protocol aims to provide confidentiality and integrity of data in transit across untrusted networks like the Internet. It is widely used to secure web traffic and e-commerce transactions on the Internet. Around 50% of all TLS traffic is currently protected using the RC4 algorithm. It has become increasingly popular because of recent attacks on CBC-mode encryption on TLS, and is now recommended by many commentators.

We have found new attacks against TLS that allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used. The attacks arise from statistical flaws in the keystream generated by the RC4 algorithm which become apparent in TLS ciphertexts when the same plaintext is repeatedly encrypted.

We have carried out experiments to demonstrate the feasibility of the attacks.

The most effective countermeasure against our attack is to stop using RC4 in TLS. There are other, less-effective countermeasures against our attacks and we have worked with a number of TLS software developers to prepare patches and security advisories.

One of the attacks also applies to WPA/TKIP, the IEEE's successor protocol to WEP. The most effective countermeasure against our attack against WPA/TKIP is to stop using WPA/TKIP and upgrade to WPA2.

Part of our work was presented at USENIX Security 2013, Washington DC, USA, 14th-16th August, 2013.

Who are we?

The team behind this research comprises Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt. Nadhem is a PhD student in the Information Security Group at Royal Holloway, University of London. Dan is a Research Professor at the University of Illinois at Chicago and a Professor at the Eindhoven University of Technology. Kenny is a Professor of Information Security and an EPSRC Leadership Fellow in the Information Security Group at Royal Holloway, University of London. Bertram and Jacob are postdocs in the Information Security Group.

What is affected?

Which versions of SSL and TLS are affected?

The attack applies to all versions of SSL and TLS that support the RC4 algorithm.

Which TLS ciphersuites are affected?

All TLS ciphersuites which include RC4 encryption are vulnerable to our attack.

Which TLS implementations are affected?

All TLS implementations which support RC4 are affected.

Which WPA/TKIP implementations are affected?

All WPA/TKIP implementations are affected.

How severe are the attacks?

Our first attack is a multi-session attack, which means that we require a target plaintext to be repeatedly sent in the same position in the plaintext stream in multiple TLS connections or sessions. It exploits single-byte biases in the initial 256 bytes of RC4 keystreams. For details of these biases, see this slide-deck showing the distributions of the first 256 output bytes from the RC4 generator (based on 2⁴⁴ random 128-bit keys).

Since the first 36 bytes of plaintext are formed from an unpredictable Finished message when SHA-1 is the selected hashing algorithm in the TLS Record Protocol, these first 36 bytes cannot be recovered. This means that the single-byte bias attack can recover 220 bytes of TLS-encrypted plaintext.

The number of connections/sessions needed to reliably recover these plaintext bytes is around 2³⁰, but already with only 2²⁴ connections/sessions, certain bytes can be recovered reliably.

The connections/sessions needed for our single-byte bias attack can be generated in various ways. The attacker could cause the TLS session to be terminated, and some applications running over TLS then automatically reconnect and retransmit a cookie or password. In a web environment, the sessions may also be generated by client-side malware, in a similar way to the BEAST attack.

This attack also applies directly to WPA/TKIP, with similar success rates, because of its use of per-packet keys for RC4. Here, the particular structure of WPA/TKIP keys means that a different set of biases are obtained in the first 256 bytes of RC4 keystream. For details, see this slide-deck showing the distributions of the first 256 output bytes from the RC4 generator (based on 2⁴¹ WPA/TKIP keys).

Our second attack applies to TLS and can be carried out in a single connection or session (but tolerates multiple connections/sessions). It exploits certain double-byte biases in RC4 keystreams (the Fluhrer-McGrew biases). It targets plaintext bytes located at any position in the TLS plaintext stream. The number of encryptions needed to reliably recover a set of 16 consecutive targeted plaintext bytes is around 10⋅2³⁰, but already with only 6⋅2³⁰ sessions, these target bytes can be recovered with 50% reliability. Since this double-byte bias attack does not require the TLS Handshake Protocol to be rerun, it can in practice be more efficient than our single-byte bias attack.

In contrast to the recent Lucky 13 attack, there is no need for sophisticated timing of error messages, and the attacker can be located anywhere on the network path between client and server in our attacks.

How does this work relate to known attacks, like BEAST, CRIME and Lucky 13?

TLS in CBC-mode has been the subject of several attacks over the years, most notably padding oracle attacks, the BEAST attack and the recent Lucky 13 attack. For more details of prior attacks, see the Lucky 13 research paper. There are now countermeasures for the BEAST and Lucky 13 attacks, and TLS in CBC-mode is believed to be secure against them once these countermeasures are applied. By contrast, the new attack targets the RC4 algorithm in TLS.

But isn't RC4 already broken?

There have been many attacks on RC4 over the years, most notably against RC4 in the WEP protocol. There, the known attacks crucially exploit the way in which the algorithm's secret key is combined with public information (the WEP IV) during the algorithm's initialisation step. These attacks do not apply to RC4 in TLS, and new attack ideas are needed. Certain bytes of the RC4 keystream are already known to have biases that assist cryptanalysis; in our work, we identify the complete set of biases in the first 256 keystream bytes and combine these using a particular statistical procedure to extract plaintext from ciphertext.

How do the attacks relate to BEAST, CRIME and Lucky 13?

The attacks are quite different from BEAST, CRIME and Lucky 13. BEAST exploits the inadvisable use of chained IVs in CBC-mode in SSL and TLS 1.0. CRIME cleverly exploits the use of compression in TLS. Lucky 13 defeats existing RFC-recommended countermeasures for padding oracle attacks against CBC-mode. Our attacks are against the RC4 algorithm and are based on analysing statistical weaknesses in the RC4 keystream. However, our attacks can be mounted using BEAST-style techniques.

Why don't the attacks have cool names?

In Western culture, naming one's attacks after obscure Neil Young albums is now considered passé.

What are the countermeasures?

For TLS, there are several possible countermeasures against our attacks. Some of these are more effective than others:

• Switch to using CBC-mode ciphersuites. This is a suitable countermeasure provided previous CBC-mode attacks such as BEAST and Lucky 13 have been patched. Many implementations of TLS 1.0 and 1.1 now do have patches against these attacks.
• Switch to using AEAD ciphersuites, such as AES-GCM. Support for AEAD ciphersuites was specified in TLS 1.2, but this version of TLS is not yet widely supported. We hope that our research will continue to spur support for TLS 1.2 in client and server implementations.
• Patch TLS's use of RC4. For example, one could discard the first output bytes of the RC4 keystream before commencing encryption/decryption. However, this would need to be carried out in every client and server implementation of TLS in a consistent manner. This solution is not practically deployable given the large base of legacy implementations and the lack of a facility to negotiate such a byte discarding procedure. Furthermore, this will not provide security against potential future improvements to our attack. Our recommendation for the long term is to avoid using RC4 in TLS and to switch to using AEAD algorithms.
• Modify browser behaviour. There are ways to modify the manner in which a browser using TLS handles HTTP GET requests to make the attack less effective. However, care is needed to avoid potential future improvements to our attack. Our recommendation for the long term is to avoid using RC4 in TLS and to switch to using AEAD algorithms.

For WPA/TKIP, the only reasonable countermeasure is to upgrade to WPA2.

Patches, advisories and press

We worked with the IETF TLS Working Group and affected vendors to disclose the attacks on TLS. We will continue to update the information here as this process continues.

• Google is focussing on implementing TLS 1.2 and AES- GCM in Chrome.
• Microsoft has modified their code so that RC4 is no longer enabled by default for TLS in Windows 8.1 Preview.
• Opera has implemented a number of countermeasures to modify browser behaviour.

• CVE: The US NIST National Vulnerability Database has accorded our single-byte bias attack on TLS CVE-2013-2566.

Is it still safe to use RC4 ?

The attacks can only be carried out by a determined attacker who can generate sufficient sessions for the attacks. They recover a limited amount of plaintext. In this sense, the attacks do not pose a significant danger to ordinary users of TLS or WPA/TKIP in their current form. However, it is a truism that attacks only get better with time, and we anticipate significant further improvements to our attacks. In addition, because of their extremely widespread use, any attacks against TLS or WPA/TKIP require careful evaluation.

Source code

We have no plans to make our source code generally available. If you are a researcher interested in replicating or extending our work, then please contact us.

Isn't it irresponsible to publish attacks on such important protocols?

In short, no. Our long-term aim is to ensure that weak encryption options are eliminated from TLS, to the eventual benefit of all users of TLS. Likewise with WPA/TKIP. Experience shows that the only way to make this happen is to make the attacks as powerful as possible and build proof-of-concept implementations of them. We have expended significant research effort to develop and prototype our attacks. We disclosed the attacks to affected vendors in advance of making our research public, and we are working with all vendors who request our assistance in assessing the attacks and implementing countermeasures.

For more information

The single-byte bias attack on RC4 was announced on 12th March 2013 during Dan Bernstein's invited talk at FSE 2013. Further information about biases in the RC4 keystream can be found in this slide-deck showing the distributions of the first 256 output bytes from the RC4 generator (based on 2⁴⁴ random 128-bit keys). Raw data for 2⁴⁵ random 128-bit keys can be found in this file. Further information about biases in the RC4 keystream for WPA/TKIP keys can be found in this slide-deck showing the distributions of the first 256 output bytes from the RC4 generator (based on 2⁴¹ WPA/TKIP keys). Full details of our attacks can be found in our research paper. A high-level overview of the results can be obtained by reading our USENIX Security 2013 presentation. Video for this talk is available on the USENIX Security 2013 website. If you have remaining questions after having studied these resources, please contact us via e-mail.

from  http://www.isg.rhul.ac.uk/tls/

------------------------------------------

How does the NSA break SSL?

A few weeks ago I wrote a long post about the NSA’s ‘BULLRUN’ project to subvert modern encryption standards. I had intended to come back to this at some point, since I didn’t have time to discuss the issues in detail. But then things got in the way. A lot of things, actually. Some of which I hope to write about in the near future.

But before I get there, and at the risk of boring you all to tears, I wanted to come back to this subject at least one more time, if only to pontificate a bit about a question that’s been bugging me.

You see, the NSA BULLRUN briefing sheet mentions that NSA has been breaking quite a few encryption technologies, some of which are more interesting than others. One of those technologies is particularly surprising to me, since I just can’t figure how NSA might be doing it. In this extremely long post I’m going to try to dig a bit deeper into the most important question facing the Internet today.

Specifically: how the hell is NSA breaking SSL?

Section of the BULLRUN briefing sheet. Source: New York Times.

To keep things on target I’m going to make a few basic ground rules.

First, I’m well aware that NSA can install malware on your computer and pwn any cryptography you choose. That doesn’t interest me at all, for the simple reason that it doesn’t scale well. NSA can do this to you, but they can’t do it for an entire population. And that’s really what concerns me about the recent leaks: the possibility that NSA is breaking encryption for the purposes of mass surveillance.

For the same reason, we’re not going to worry about man-in-the-middle (MITM) attacks. While we know that NSA does run these, they’re also a very targeted attack. Not only are MITMs detectable if you do them at large scale, they don’t comport with what we know about how NSA does large-scale interception — mostly via beam splitters and taps. In other words: we’re really concerned about passive surveillance.

The rules above aren’t absolute, of course. We will consider limited targeted attacks on servers, provided they later permit passive decryption of large amounts of traffic; e.g., decryption of traffic to major websites. We will also consider arbitrary modifications to software and hardware — something we know NSA is already doing.

One last point: to keep things from going off the rails, I’ve helpfully divided this post into two sections. The first will cover attacks that use only known techniques. Everything in this section can be implemented by a TAO employee with enough gumption and access to software. The second section, which I’ve titled the ‘Tinfoil Hat Spectrum‘ covers the fun and speculative stuff — ranging from new side channel attacks all the way to that huge quantum computer the NSA keeps next to BWI.

We’ll start with the ‘practical’.

Attacks that use Known Techniques

Theft of RSA keys. The most obvious way to ‘crack’ SSL doesn’t really involve cracking anything. Why waste time and money on cryptanalysis when you can just steal the keys? This issue is of particular concern in servers configured for the TLS RSA handshake, where a single 128-byte server key is all you need to decrypt every past and future connection made from the device.

In fact, this technique is so obvious that it’s hard to imagine NSA spending a lot of resources on sophisticated cryptanalytic attacks. We know that GCHQ and NSA are perfectly comfortable suborning even US providers overseas. And inside our borders, they’ve demonstrated a willingness to obtain TLS/SSL keys using subpoena powers and gag orders. If you’re using an RSA connection to a major website, it may be sensible to assume the key is already known.

Of course, even where NSA doesn’t resort to direct measures, there’s always the possibility of obtaining keys via a remote software exploit. The beauty is that these attacks don’t even require remote code execution. Given the right vulnerability, it may simply require a handful of malformed SSL requests to map the full contents of the OpenSSL/SChannel heap.

Source: New York Times

Suborning hardware encryption chips. A significant fraction of SSL traffic on the Internet is produced by hardware devices such as SSL terminators and VPN-enabled routers. Fortunately we don’t have to speculate about the security of these devices — we already know NSA/GCHQ have been collaborating with hardware manufacturers to ‘enable’ decryption on several major VPN encryption chips.

The NSA documents aren’t clear on how this capability works, or if it even involves SSL. If it does, the obvious guess is that each chip encrypts and exflitrates bits of the session key via ‘random’ fields such as IVs and handshake nonces. Indeed, this is relatively easy to implement on an opaque hardware device. The interesting question is how one ensures these backdoors can only be exploited by NSA — and not by rival intelligence agencies. (Some thoughts on that here.)

Side channel attacks. Traditionally when we analyze cryptographic algorithms we concern ourselves with the expected inputs and outputs of the system. But real systems leak all kinds of extra information. These ‘side channels’ — which include operation time, resource consumption, cache timing, and RF emissions — can often be used to extract secret key material.

The good news is that most of these channels are only exploitable when the attacker is in physical proximity to a TLS server. The bad news is that there are conditions in which the attacker can get close. The most obvious example involves virtualized TLS servers in the cloud setting, where a clever attacker may share physical resources with the target device.

A second class of attack uses remote timing information to slowly recover an RSA key. These attacks can be disabled via countermeasures such as RSA blinding, though amusingly, some ‘secure’ hardware co-processors may actually turn these countermeasures off by default! At very least, this makes the hardware vulnerable to attacks by a local user, and could even facilitate remote recovery of RSA keys.

Weak random number generators. Even if you’re using strong Perfect Forward Secrecy ciphersuites, the security of TLS depends fundamentally on the availability of unpredictable random numbers. Not coincidentally, tampering with random number generator standards appears to have been a particular focus of NSA’s efforts.

Random numbers are critical to a number of elements in TLS, but they’re particularly important in three places:

1. On the client side, during the RSA handshake. The RNG is used to generate the RSA pre-master secret and encryption padding. If the attacker can predict the output of this generator, she can subsequently decrypt the entire session. Ironically, a failure of the server RNG is much less devastating to the RSA handshake.*
2. On the client or server side, during the Diffie-Hellman handshake(s). Since Diffie-Hellman requires a contribution from each side of the connection, a predictable RNG on either side renders the session completely transparent.
3. During long-term key generation, particularly of RSA keys. If this happens, you’re screwed.

And you just don’t need to be that sophisticated to weaken a random number generator. These generators are already surprisingly fragile, and it’s awfully difficult to detect when one is broken. Debian’s maintainers made this point beautifully back in 2008 when an errant code cleanup reduced the effective entropy of OpenSSL to just 16 bits. In fact, RNGs are so vulnerable that the challenge here is not weakening the RNG — any idiot with a keyboard can do that — it’s doing so without making the implementation trivially vulnerable to everyone else.

The good news is that it’s relatively easy to tamper with an SSL implementation to make it encrypt and exfiltrate the current RNG seed. This still requires someone to physically alter the library, or install a persistent exploit, but it can be done cleverly without even adding much new code to the existing OpenSSL code. (OpenSSL’s love of function pointers makes it particularly easy to tamper with this stuff.)

If tampering isn’t your style, why not put the backdoor in plain sight? That’s the approach NSA took with the Dual_EC RNG, standardized by NIST in Special Publication 800-90. There’s compelling evidence that NSA deliberately engineered this generator with a backdoor — one that allows them to break any TLS/SSL connection made using it. Since the generator is (was) the default in RSA’s BSAFE library, you should expect every TLS connection made using that software to be potentially compromised.

And I haven’t even mentioned Intel’s plans to replace the Linux kernel RNG with its own hardware RNG.

Esoteric Weaknesses in PFS systems. Many web servers, including Google and Facebook, now use Perfect Forward Secrecy ciphersuites like ephemeral Diffie-Hellman (DHE and ECDHE). In theory these ciphersuites provide the best of all possible worlds: keys persist for one session and then disappear once the connection is over. While this doesn’t save you from RNG issues, it does make key theft a whole lot more difficult.

PFS ciphersuites are a good thing, but a variety of subtle issues can cramp their style. For one thing, the session resumption mechanism can be finicky: session keys must either be stored locally, or encrypted and given out to users in the form of session tickets. Unfortunately, the use of session tickets somewhat diminishes the ‘perfectness’ of PFS systems, since the keys used for encrypting the tickets now represent a major weakness in the system. Moreover, you can’t even keep them internal to one server, since they have to be shared among all of a site’s front-end servers! In short, they seem like kind of a nightmare.

A final area of concern is the validation of Diffie-Hellman parameters. The current SSL design assumes that DH groups are always honestly generated by the server. But a malicious implementation can violate this assumption and use bad parameters, which enable third party eavesdropping. This seems like a pretty unlikely avenue for enabling surveillance, but it goes to show how delicate these systems are.

The Tinfoil Hat Spectrum

I’m going to refer to the next batch of attacks as ‘tinfoil hat‘ vulnerabilities. Where the previous issues all leverage well known techniques, each of the following proposals require totally new cryptanalytic techniques. All of which is a way of saying that the following section is pure speculation. It’s fun to speculate, of course. But it requires us to assume facts not in evidence. Moreover, we have to be a bit careful about where we stop.

So from here on out we are essentially conducting a thought-experiment. Let’s imagine the NSA has a passive SSL-breaking capability; and furthermore, that it doesn’t rely on the tricks of the previous section. What’s left?

The following list begins with the most ‘likely’ theories and works towards the truly insane.

Breaking RSA keys. There’s a persistent rumor in our field that NSA is cracking 1024-bit RSA keys. It’s doubtful this rumor stems from any real knowledge of NSA operations. More likely it’s driven by the fact that cracking 1024-bit keys is highly feasible for an organization with NSA’s resources.

How feasible? Several credible researchers have attempted to answer this question, and it turns out that the cost is lower than you think. Way back in 2003, Shamir and Tromer estimated $10 million for a purpose-built machine that could factor one 1024-bit key per year. In 2013, Tromer reduced those numbers to about $1 million, factoring in hardware advances. And it could be significantly lower. This is pocket change for NSA.

Along similar lines, Bernstein, Heninger and Lange examined at the feasibility of cracking RSA using distributed networks of standard PCs. Their results are pretty disturbing: in principal, a cluster about the size of the real-life Conficker botnet could do serious violence to 1024-bit keys.

Given all this, you might ask why this possibility is even in the ‘tinfoil hat’ category. The simple answer is: because nobody’s actually done it. That means it’s at least conceivable that the estimates above are dramatically too high — or even too low. Moreover, RSA-1024 keys are being rapidly being phased out. Cracking 2048 bit keys would require significant mathematical advances, taking us much deeper into the tinfoil hat.**

Cracking RC4. On paper, TLS supports a variety of strong encryption algorithms. In practice, about half of all TLS traffic is secured with the creaky old RC4 cipher. And this should worry you — because RC4 is starting to show its age. In fact, as used in TLS it’s already vulnerable to (borderline) practical attacks. Thus it seems like a nice candidate for a true cryptanalytic advance on NSA’s part.

Unfortunately the problem with this theory is that we simply don’t know of any attack that would allow the NSA to usefully crack RC4! The known techniques require an attacker to collect thousands or millions of ciphertexts that are either (a) encrypted with related keys (as in WEP) or (b) contain the same plaintext. The best known attack against TLS takes the latter form — it requires the victim to establish billions of sessions, and even then it only recovers fixed plaintext elements like cookies or passwords.

The counterargument is that the public research community hasn’t been thinking very hard about RC4 for the past decade — in part because we thought it was so broken people had stopped using it (oops!) If we’d been focusing all our attention on it (or better, the NSA’s attention), who knows what we’d have today.

If you told me the NSA had one truly new cryptanalytic capability, I’d agree with Jake and point the finger at RC4. Mostly because the alternatives are far scarier.

New side-channel attacks. For the most part, remote timing attacks appear to have been killed off by the implementation of countermeasures such as RSA blinding, which confound timing by multiplying a random blinding factor into each ciphertext prior to decryption. In theory this should make timing information essentially worthless. In practice, many TLS implementations implement compromises in the blinding code that might resurrect these attacks, things like squaring a blinding factor between decryption operations, rather than generating a new one each time. It’s quite unlikely there are attacks here, but who knows.

Goofy stuff. Maybe NSA does have something truly amazing up its sleeve. The problem with opening this Pandora’s box is that it’s really hard to get it closed again. Did Jerry Solinas really cook the NIST P-curves to support some amazing new attack (which NSA knew about way back in the late 1990s, but we have not yet discovered)? Does the NSA have a giant supercomputer named TRANSLTR that can brute-force any cryptosystem? Is there a giant quantum computer at the BWI Friendship annex? For answers to these questions you may as well just shake the Magic 8-Ball, cause I don’t have a clue.

Conclusion

We don’t know and can’t know the answer to these things, and honestly it’ll make you crazy if you start thinking about it. All we can really do is take NSA/GCHQ at their word when they tell us that these capabilities are ‘extremely fragile’. That should at least give us hope.

The question now is if we can guess well enough to turn that fragility from a warning into a promise.

Notes:

* A failure of the server RNG could result in some predictable values like the ServerRandom and session IDs. An attacker who can predict these values may be able to run active attacks against the protocol, but — in the RSA ciphersuite, at least — they don’t admit passive compromise.

** Even though 1024-bit RSA keys are being eliminated, many servers still use 1024-bit for Diffie-Hellman (mostly for efficiency reasons). The attacks on these keys are similar to the ones used against RSA — however, the major difference is that fresh Diffie-Hellman ‘ephemeral’ keys are generated for each new connection. Breaking large amounts of traffic seems quite costly.

from https://blog.cryptographyengineering.com/2013/12/03/how-does-nsa-break-ssl/

--------------------------------------------------------------- 

How to choose an Authenticated Encryption mode

If you’ve hung around this blog for a while, you probably know how much I like to complain. (Really, quite a lot.) You might even be familiar with one of my favorite complaints: dumb crypto standards. More specifically: dumb standards promulgated by smart people.

The people in question almost always have justifications for whatever earth-shakingly stupid decision they’re about to take. Usually it’s something like ‘doing it right would be hard‘, or ‘implementers wouldn’t be happy if we did it right‘. Sometimes it’s ‘well, we give the option to do it right‘. In the worst case they’ll tell you: ‘if it bothers you so much, why don’t you join the committee and suggest that idea yourself, Mr. Smartypants‘.

Well, first of all, it’s Dr. Smartypants. And moreover, I’ve tried. It doesn’t work.

Case in point: I happen to be lurking on the mailing list of a standards committee that recently decided to allow unauthenticated CBC mode encryption as an option in their new web encryption standard. When I pointed out that the exact same decision led to the failure of a previous standard — ironically, one that this new standard will probably replace — I was told, politely, that:

1. Mandating authenticated encryption would be hard.
2. Real implementers don’t know how to implement it.
3. We already offer the option to use authenticated encryption.
4. Stop telling us things we already know.

The worst part: they really did know. The committee included some smart, smart people. People who know that this is a bad idea, and who have decided either to just go with it, or else have convinced themselves that implementers won’t (a) pick the easy, insecure option, and then (b) screw it up completely. I have news for these people: Yes, they will. This is why we write standards.

After all this build-up, it may surprise you that this is not a post about standards committees. It’s not even a post about smart people screwing things up. What I’m here to talk about today is Authenticated Encryption, what the hell it is, why you need it. And finally, (assuming you’re good with all that) which of the many, many AE schemes should you consider for your application.

First, some background.

What’s Authenticated Encryption and why should I care?

For those of you who don’t know what AE is, I first need to explain one basic fact that isn’t well explained elsewhere:

Nearly all of the symmetric encryption modes you learned about in school, textbooks, and Wikipedia are (potentially) insecure.

This covers things like AES when used in standard modes of operation like CBC and CTR. It also applies to stream ciphers like RC4. Unfortunately, the list of potentially insecure primitives includes many of the common symmetric encryption schemes that we use in practice.

Now, I want to be clear. These schemes are not insecure because they leak plaintext information to someone who just intercepts a ciphertext. In fact, most modern schemes hold up amazingly well under that scenario, assuming you choose your keys properly and aren’t an idiot.

The problem occurs when you use encryption in online applications, where an an adversary can intercept, tamper with, and submit ciphertexts to the receiver. If the attacker can launch such attacks, many implementations can fail catastrophically, allowing the attacker to completely decrypt messages.

Sometimes these attacks requires the attacker to see only an error message from the receiver. In other cases all he needs to do is measure time it takes for the receiver to acknowledge the submission. This type of attack is known as a chosen ciphertext attack, and by far the most common embodiment is the ‘padding oracle attack‘ discovered in 2002 by Serge Vaudenay. But there are others.

The simplest way to protect yourself against these attacks is to simply MAC your ciphertexts with a secure Message Authentication Code such as HMAC-SHA. If you prefer this route, there are two essential rules:

1.  Always compute the MACs on the ciphertext, never on the plaintext.
2.  Use two different keys, one for encryption and one for the MAC.

Rule (1) prevents chosen-ciphertext attacks on block cipher modes such as CBC, since your decryption process can reject those attacker-tampered ciphertexts before they’re even decrypted. Rule (2) deals with the possibility that your MAC and cipher will interact in some unpleasant way. It can also help protect you against side-channel attacks.

This approach — encrypting something, then MACing it — is not only secure, it’s provably secure as long as your encryption scheme and MAC have certain properties. Properties that most common schemes do seem to possess.*

Dedicated AE(AD) modes

Unfortunately, the ‘generic composition’ approach above is not the right answer for everyone. For one thing, it can be a little bit complicated. Moreover, it requires you to implement two different primitives (say, a block cipher and a hash function for HMAC), which can be a hassle. Last, but not least, it isn’t necessarily the fastest way to get your messages encrypted.

The efficiency issue is particularly important if you’re either (a) working on a constrained device like an embedded system, or (b) you’re working on a fast device, but you just need to encrypt lots of data. This is the case for network encryptors, which have to process data at line speeds — typically many gigabytes per second!

For all of these reasons, we have specialized block cipher modes of operation called Authenticated Encryption (AE) modes, or sometimes Authenticated Encryption with Associated Data (AEAD). These modes handle both the encryption and the authentication in one go, usually with a single key.

AE(AD) modes were developed as a way to make the problem of authentication ‘easy’ for implementers. Moreover, some of these modes are lightning fast, or at least allow you to take advantage of parallelization to speed things up.

Unfortunately, adoption of AE modes has been a lot slower than one would have hoped for, for a variety of reasons. One of which is: it’s hard to find good implementations, and another is that there are tons and tons of AE(AD) schemes.

So, which AE mode should I choose?

And now we get down to brass tacks. There are a plethora of wonderful AE(AD) modes out there, but which one should you use? There are many things to consider. For example:

• How fast is encryption and decryption?
• How complicated is the implementation?
• Are there free implementations out there?
• Is it widely used?
• Can I parallelize it?
• Is it ‘on-line’, i.e., do I need to know the message length before I start encrypting?
• Is it patented?
• Does it allow me to include Associated Data (like a cleartext header)?
• What does Matt Green think about it?

To answer these questions (and particularly the most important final one), let’s take a look at a few of the common AE modes that are out there. All of these modes support Associated Data, which means that you can pre-pend an unencrypted header to your encrypted message if you want. They all take a single key and some form of Initialization Vector (nonce). Beyond that, they’re quite different inside.

GCM. Galois Counter Mode has quietly become the most popular AE(AD) mode in the field today, despite the fact that everyone hates it. The popularity is due in part to the fact that GCM is extremely fast, but mostly it’s because the mode is patent-free. GCM is ‘on-line’ and can be parallelized, and (best): recent versions of OpenSSL and Crypto++ provide good implementations, mostly because it’s now supported as a TLS ciphersuite. As a side benefit, GCM will occasionally visit your house and fix broken appliances.

Given all these great features, you might ask: why does everyone hate GCM? In truth, the only people who hate GCM are those who’ve had to implement it. You see, GCM is CTR mode encryption with the addition of a Carter-Wegman MAC set in a Galois field. If you just went ‘sfjshhuh?’, you now understand what I’m talking about. Implementing GCM is a hassle in a way that most other AEADs are not. But if you have someone else’s implementation — say OpenSSL’s — it’s a perfectly lovely mode.

OCB. In performance terms Offset Codebook Mode blows the pants off of all the other modes I mention in this post. It’s ‘on-line’ and doesn’t require any real understanding of Galois fields to implement** — you can implement the whole thing with a block cipher, some bit manipulation and XOR. If OCB was your kid, he’d play three sports and be on his way to Harvard. You’d brag about him to all your friends.

Unfortunately OCB is not your kid. It belongs to Philip Rogaway, who also happens to hold a patent on it. This is no problem if you’re developing GPL software (it’s free for you), but if you want to use it in a commercial product — or even license under Apache — you’ll probably have to pay up. As a consequence OCB is used in approximately no industry standards, though you might find it in some commercial products.

EAX. Unlike the other modes in this section, EAX mode doesn’t even bother to stand for anything. We can guess that E is Encryption and A is Authentication, but X? I’m absolutely convinced that EAX is secure, but I cannot possibly get behind a mode of operation that doesn’t have a meaningful acronym.

EAX is a two-pass scheme, which means that encryption and authentication are done in separate operations. This makes it much slower than GCM or OCB, though (unlike CCM) it is ‘on-line’. Still, EAX has three things going for it: first, it’s patent-free. Second, it’s pretty easy to implement. Third, it uses only the Encipher direction of the block cipher, meaning that you could technically fit it into an implementation with a very constrained code size, if that sort of thing floats your boat. I’m sure there are EAX implementations out there; I just don’t know of any to recommend.

Whatever you do, be sure not to confuse EAX mode with its dull cousin EAX(prime), which ANSI developed only so it could later be embarrassingly broken.

CCM. Counter Mode with CBC MAC is the 1989 Volvo station wagon of AEAD modes. It’ll get you to your destination reliably, just not in a hurry. Like EAX, CCM is also a two-pass scheme. Unfortunately, CCM is not ‘on-line’, which means you have to know the size of your message before you start encrypting it. The redeeming feature of CCM is that it’s patent-free. In fact, it was developed and implemented in the 802.11i standard (instead of OCB) solely because of IP concerns. You can find an implementation in Crypto++.

The rest. There are a few more modes that almost nobody uses. These include XCBC, IAPM and CWC. I have no idea why the first two haven’t taken off, or if they’re even secure. CWC is basically a much slower version of GCM mode, so there’s no real reason to use it. And of course, there are probably plenty more that I haven’t listed. In general: you should use those at your own risk.

Summing up

So where are we?

In general, the decision of which cipher mode to use is not something most people make every day, but when you do make that decision, you need to make the right one. Having read back through the post, I’m pretty sure that the ‘right’ answer for most people is to use GCM mode and rely on a trusted free implementation, like the one you can get from OpenSSL.

But there are subcases. If you’re developing a commercial product, don’t care about cross-compatibility, and don’t mind paying ‘a small one-time fee‘, OCB is also a pretty good option. Remember: even cryptographers need to eat.

Finally, if you’re in the position of developing your own implementation from scratch (not recommended!) and you really don’t feel confident with the more complicated schemes, you should serious consider EAX or CCM. Alternatively, just use HMAC on your ciphertexts. All of these things are relatively simple to deal with, though they certainly don’t set the world on fire in terms of performance.

The one thing you should not do is say ‘gosh this is complicated, I’ll just use CBC mode and hope nobody attacks it’, at least not if you’re building something that will potentially (someday) be online and subject to active attacks like the ones I described above. There’s already enough stupid on the Internet, please don’t add more.

Notes:

* Specifically, your encryption scheme must be IND-CPA secure, which would apply to CBC, CTR, CFB and OFB modes implemented with a secure block cipher. Your MAC must be existentially unforgeable under chosen message attack (EU-CMA), a property that’s (believed) to be satisfied by most reasonable instantiations of HMAC.

** An earlier version of this post claimed that OCB didn’t use Galois field arithmetic. This commenter on Reddit correctly points out that I’m an idiot. It does indeed do so. I stand by my point that the implementation is dramatically simpler than GCM.

from https://blog.cryptographyengineering.com/2012/05/19/how-to-choose-authenticated-encryption/

-------------------

Is RC4 safe for use in SSL?

August 28, 2009

I received a rather interesting and informative couple of emails last week from Paweł Krawczyk, who wanted to make a point how RC4 is still safe to use in SSL. I thought that his comments would be of interest to a wider audience, so here they are (with permission):

[...] TLS_RSA_WITH_RC4_128_MD5 [...] is extremely widespread among commercial servers. Main reasons are 1) it's default preferred cipher in most versions of IIS, 2) these two algorithms are absolutely fastest and least CPU-intensive.

However, because there are known cryptoanalytic attacks against both RC4 and MD5, this ciphersuite is notoriously reported as "weak" by some pentesting tools and teams.

This is not true or at least not accurate, as the specific usage of RC4 and MD5 - in SSLv3 with 128 bit key - has no known and working attacks. That's one reason why PCI-DSS v1.2 now doesn't list any specific algorithms for SSL but instead just says you should use "strong" ones. And widespread usage of TLS_RSA_WITH_RC4_128_MD5 among financial organisations seems to confirm the interpretation that it's still considered a strong ciphersuite.

On the other hand NIST SP 800-52 doesn't allow neither RC4 or MD5 because they're not FIPS-approved algorithms, with one exception - connecting in client mode to external, commercial systems with this specific ciphersuite enabled. Which seems to set the balance quite even, because SP is only binding for US federal agencies.

And...

There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL.

Further resources:

• RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4
• Forgery and Partial Key Recovery attacks on HMAC and NMAC using Hash Collisions (PDF; concludes HMAC-MD5, HMAC-SHA1 - No immediate practical threats) 

from https://blog.ivanristic.com/2009/08/is-rc4-safe-for-use-in-ssl.html

-------------------------------------------------------------------------------------------------------

 

OpenSSL中的CipherList（加密算法套件）

每种Cipher的名字里包含了四部分信息，分别是:

• 密钥交换算法，用于决定客户端与服务器之间在握手的过程中如何认证，用到的算法包括RSA，Diffie-Hellman，ECDH，PSK等
• 加密算法，用于加密消息流，该名称后通常会带有两个数字，分别表示密钥的长度和初始向量的长度，比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256
• 报文认证信息码（MAC）算法，用于创建报文摘要，确保消息的完整性（没有被篡改），算法包括MD5，SHA等。
• PRF（伪随机数函数），用于生成“master secret”。

比如： TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ，从其名字可知，它是：

• 基于TLS协议的；
• 使用ECDHE、RSA作为密钥交换算法；
• 加密算法是AES（密钥和初始向量的长度都是256）；
• MAC算法（这里就是哈希算法）是SHA。

比如： TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

“TLS” 自然是指TLS协议
“ECDHE” 是说使用带有短暂性密钥的椭圆曲线Diffie-Hellman密钥交换（也就是说要为每个会话创建新密钥并且事后也不会记下来）
“RSA”表明用 RSA 非对称加密保护TLS握手的安全
“AES_128_CBC” 是说在密码块链接模式中用带有128位密钥的AES 非对称加密保护真正的数据交换
“SHA” 表明用 SHA 安全哈希算法。

-------------

[译]使用AES 256以达到SSL/TLS安全最大化

原文链接：https://luxsci.com/blog/256-bit-aes-encryption-for-ssl-and-tls-maximal-security.html

本博文仅仅是上述原文的翻译，仅供研究参考，本人不对准确性作任何保证，侵立删，如有转载，需自行承担所有责任。如有翻译不准确的地方，欢迎指教。

SSL/TLS是当今因特网上保护传输安全的重量级角色。然而，很多人并不知道安全的等级可以跨越“几乎没什么卵用”到“真的非常非常安全，美国政府TOP SECRET级别的数据都可使用”，等级变换的关键点在于“密码”或“密码技术”。有许多种密码：一些很快但不安全，一些很慢但非常安全。不安全密码的一个例子是“出口级密码”，当年美帝不允许将其出口至其他国家。

 AES （高级加密标准）是比DES更新的加密算法。AES在2001年成为标准，在此之前经过了5年的审核，如今AES是最为流行的对称密码算法（SSL/TLS协议进行传输数据加密的实际算法）之一。它是加密技术的“黄金标准”，很多安全敏感的组织都要求其雇员使用AES-256进行通信数据的加密。

本文讨论AES以及它在SSL（多WEB浏览器和EMAIL程序都支持SSL协议）中的角色，以及如何保证所有的安全通信都使用AES256加密呢，还有其他更多的内容。

深入理解AES

大多数密码库对AES的支持都有相当长一段时间了。openssl对其的支持是从2002年的v0.9.7版本开始的。openssl是unix和linux环境下最为流行的SSL基础库，例如在LuxSci中，GPG（PGP的开源实现）中也包含了对AES256的支持。

AES是当前的新宠，已经成功的渗透到大多数软件中。但是，正如我们将要看到的，这并不意味着在你的计算机中已经实际使用到它了。

AES256有多安全

AES是FIPS（联邦信息处理标准）认证的算法，并且目前尚未有除了暴力破解外的其他攻击方式（除了一些针对AES处理的旁路分时攻击，但并不适用于网络环境和SSL）。实际上，AES的安全是如此之强，美国政府的“绝密（top secret）”级别信息都可使用其进行加密。

 

AES算法设计的具有不同的密钥长度（128、192、256），目的是提供对从“已分类信息（ classified information）"到”机密信息（SECRET ）“都提供适当的保护。绝密（TOP SECRET）级信息需要使用192或256长度的密钥。为了保护国家安全系统/信息的AES实现在使用之前必须通过NAS的认证 (Lynn Hathaway, June 2003 – reference.)。

 

如果你正在选择加密算法，AES256是一个不错的选择，虽然AES128和AES192的也不错。

Beast Attack和SSL安全相关站点

针对保护Web通信的SSL协议的攻击，广为人知的是Beast攻击。在此攻击中，位于你网络可信区域的攻击者可以进入你的SSL Session并且窃听通信数据。

解决办法是使用TLS v1.1+的密码算法。BEAST攻击如如今不再被认为是一个很重要的攻击。

参看:

• Is SSL/TLS really broken by the Beast Attack?
• Mitigating The Beast  attack.
• Is the beast still a threat?

有除了AES之外的选择吗？

 SSL/TLS中有许多可选的密码算法，一个不错的选择是“3DES”（例如，出于兼容XP系统的目的）。出于已知的弱点，我们不建议使用RC4算法。FIST/NIST给出了高安全级别的推荐算法，这些算法基本上都是AES或DES结合不同的哈希算法、密钥交换协议。

SSL/TLS会话中如何选择密码算法？

一般而言，当SSL客户端（例如email程序或WEB浏览器）向服务器发起SSL或TLS连接时，客户端发送它所支持的加密算法列表。服务器顺序检查该列表，并且选择自身也支持的第一个匹配项。客户端一般将最安全的算法放在第一位，因此客户端和服务端将会选择双方都支持的最安全的算法。不过客户端有时会权衡安全和速度，也可能会导致选择了次优算法。

大多数支持SSL的现代WEB和EMAIL服务器（例如LuxSci.com的服务器）支持很多种不同的强加密技术，包括128位的RC4和256位的AES。它们提供了一系列算法而非只有一个最优的，这允许那些使用较老软件的访问者仍能享受加密的好处，即使其安全强度比理想中要低很多。

另外，大多数提供安全服务的公司都禁止使用那些安全强度过低的算法，这些算法可能很容易的被攻破（例如曾广泛使用的出口级密码）。因此，如果你访问一个基于SSL或TLS提供的声誉良好的服务，加密类型的选择基本上是由你的客户端程序（例如email程序或WEB浏览器）根据服务端提供的选项及选项排列来决定的。

现代浏览器都支持那些加密技术？

对于任何浏览器，通过访问如下网址可以很方便的看到它所支持的最佳加密技术：https://www.howsmyssl.com/

通过对一些浏览器的检查，可以得到下表：

浏览器	操作系统	最佳密码算法	结论?
Native Android Browser (LG G3)	Android v4.4.2+	AES 256-bit	Good!
Chrome v39+	Android v4.4.2+	AES 256-bit	Good!
FireFox Mobile v8+	Android	AES 256-bit	Good!
Safari	iOS v8+ (iPhone/iPad/etc.)	AES 256-bit	Good
Safari	iOS v5.0.1	AES 128-bit	Good
Safari	iOS v2.2	AES 128-bit	Good
Silk	Kindle Fire	RC4 128-bit	Fair
FireFox v35+	Windows XP & Vista, Mac OSX	AES 256-bit	Good!
FireFox v8+	Windows XP & Vista, Mac OSX	AES 256-bit	Good!
FireFox v3.0.5	Windows XP & Vista, Mac OSX	AES 256-bit	Good!
Safari v8+	Windows Vista/7, Mac OSX	AES 256-bit	Good
Safari v5.1.2	Windows Vista/7, Mac OSX	AES 128-bit	Good
Safari v3.2.1	Windows Vista, Mac OSX	AES 128-bit	Good
Safari v3.2.1	Windows XP	RC4 128-bit	Fair
Chrome v40+	Windows Vista/7, Mac OSX	AES 256-bit	Good!
Chrome v15+	Windows Vista/7, Mac OSX	AES 256-bit	Good!
Chrome v1.x	Windows Vista	AES 128-bit	Good
Chrome v1.x	Windows XP	RC4 128-bit	Fair
Internet Explorer v11	Windows 7	AES 256-bit	Good
Internet Explorer v9	Windows 7	AES 128-bit	Good
Internet Explorer v9	Windows Vista	RC4 128-bit	Fair
Internet Explorer v7 & v8	Windows Vista	AES 128-bit	Good
Internet Explorer v8	Windows XP	RC4 128-bit	Fair
Internet Explorer v7	Windows XP	RC4 128-bit	Fair
Internet Explorer v6	Windows XP	RC4 128-bit	Fair
Opera v26+	Mac OSX	AES 256-bit	Good!
Opera v11.10+	Windows Vista	AES 256-bit	Good!
Opera v9.62	Windows XP & Vista	AES 256-bit	Good!

从上表可以看出，即使环境支持AES算法，也仅仅只有某些浏览器会默认使用AES算法。我们也看到任何使用Windows默认SSL库的程序在XP上会使用RC4算法，在Vista上会使用128位的AES算法。因此，使用XP或Win2000系统的同学最好使用有自己SSL算法管理器的浏览器（例如Firefox，Opera）。

现代Email程序都支持那些加密技术？

这里的Email程序不包括使用浏览器。很显然，如果使用WebMail访问邮箱，该问题的答案取决于使用的是什么浏览器。

注意Email连接不受Beast攻击的影响。

我们测试了一些流行的Email程序，以测试它们与支持多种强加密算法的服务器连接时会选择何种密码算法.¹ 结果见下表：

Email程序	操作系统	结论?	结果
Mozilla Thunderbirdv2+	Windows XP & Vista	Good!	256-bit AES
Thunderbird v2+	Mac OSX v10.4.11	Good!	256-bit AES
Outlook 2010	Windows 7	Good!	256-bit AES
Outlook 2007	Windows XP	Fair	128-bit RC4 is the best supported
Outlook 2007	Windows Vista	Good	128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and thus not used)
Outlook 2003	Windows XP	Fair	128-bit RC4 is the best supported
Mail.app	Mac OSX v10.10	Good	256-bit AES
Mail.app	Mac OSX v10.5.5	Good	128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and thus not used)
Mail.app	Mac OSX v10.4.11	Good	128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and thus not used)
Mail.app	iPhone v2.2	Good	128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and thus not used)
Eudora v7	Windows XP	Good	256-bit AES
Eudora v8	Mac OSX v10.4	Good	256-bit AES
Entourage v12	Mac OSX v10.4	Fair	DES

我们看到了类似的模式，大多数情况下，密码算法的选择取决于操作系统而不是程序。一些程序使用其自身的SSL库（例如Thunderbird/Eudora），一些使用的是操作系统内建的库。因此，我们可以推断出在Vista或Windows7+上的新版Outlook将会至少支持128位的AES，XP系统上的大部分程序将使用128位的RC4。

如何强制浏览器和Email程序使用256位AES？

如前讨论，email客户端的选择是决定加密算法使用的首要要素（？似不符，应是指使用自己SSL库的email客户端）。例如，如果使用Firefox或Opera进行Web访问，使用Thunderbird访问email，将会使用245位的AES算法，当然前提是服务器也支持。

然而，如果你想更进一步，保证只有在使用256位AES算法时才进行安全连接，这也是可行的。如果你的组织强制要求使用256位AES，或你不信任那些使用其他算法的服务器，可以考虑这种方法。

上述方式在另外一种场景下也是非常有用的：你正在连接的Web站点将RC4算法放在了AES算法之前，但是你知道你的浏览器是不受Beast攻击影响的（例如你使用了TLS v1.1+的协议），并且你更倾向于使用AES。现在，大多数现代浏览器的新版本（例如Ie、Firefox、Chrome、Opera）都是Beast免疫的。但是，浏览器的旧版本还是会受Beast攻击的影响。

根据下面的指导，你可以确保256位的AES算法应用于所有的安全连接，如果服务端不支持AES256则连接会失败。如果你有其他操作系统或程序的设置方式，请留言告知我们。

注意如果你移除了RC4算法的支持，你可能无法访问一些站点，那些只支持RC4的站点，我们办公室旁边支持网上订餐的Pizza店就是个例子。

Mozilla Firefox:

1. 在地址栏输入“about:config” 并回车，打开配置参数的详细列表。
2. 确保 “security.tls.version.min”是“1”，以便关闭对SSLv2和SSLv3的支持。
3. 搜索 “security.ssl3“。
4. 将名字中不含“aes_256”的所有算法项（例如RC4、camellia、des等）的值都改为“false”。这将会使得它们不再可用。
5. 你将只剩下TLS  v1.0+和AES256的各项。
6. 你甚至无需重启Firefox即可生效。

注意Firefox有一个非常NB的插件叫“CipherFox”，它允许你查看所连接站点的密码算法信息。

Mozilla Thunderbird: (也可参看 optimization tips for Thunderbird)

1. 从“Tools”菜单选择“Options”。
2. 在“Option”对话框的“Advanced”标签页的“General”区，点击“Config Editor...”按钮。
3. 采取同Firefox设置类似的操作，禁用SSLv2和SSLv3，关闭所有名字中不包括“aes_256”的算法。
4. 重启Thunderbird以便一些持久化的连接关闭并且重新打开。
5. 确保你的email帐号都配置为使用SSL或TLS，不是“if available”，而是“always”。
6. 如果你的email提供商支持，彻底的禁用你帐号的不安全连接。这将会导致连接失败，即使email程序意外的配置为安全连接（？）。

Google Chrome

Chrome使用操作系统的SSL设置。因此，如果你从操作系统上改变了密码算法顺序或移除了RC4（方法见下面），这将会解决你在Chrome上的问题。

我们发现如果使用一些额外的命令行参数启动Chrome，可以强制使用TLS1.0+并且可以阻止某些密码算法的使用，例如：将下述参数添加至Chrome快捷方式（以Arguments的方式）或命令行。

--ssl-version-min=tls1 --cipher-suite-blacklist=0x0005,0x0004,0xc011,0xc007

将会阻止RC4算法的使用.

Internet Explorer

为了禁用RC4算法，并设置AES256为主要算法，你需要在Windows操作系统中更改密码算法支持。方法参看下面。

Skype:

• 稍微偏离了点主题，但 Skype 使用256位的AES加密算法，因此如果你使用它聊天或语音电话，你的数据将会以这种方式加密。

Windows Vista, Windows 7+

我们已经看到，Windows Vista及更高的版本支持256位的AES，但是它将128位AES放在了列表的首位，因此这也是windows环境中大多数依赖于Windows内建SSL模块程序的工作方式（例如IE、Chrome、Outlook等）。

如果你的Windows是“小企业版”及以上的版本，你可以通过使用“组策略编辑器”移除不想使用的密码算法，也可改变算法的出现顺序。例如，为了将AES256而不是AES128或RC4设为默认选择，可参考这些指引：

1. 通过在命令行窗口中键入gpedit.mscd打开组策略编辑器。
2. 选择Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
3. 只有一个条目: SSL Cipher Suite Order. 打开它。
4. 选择Enabled.
5. 现在你需要小心操作。你将会看到同上面一样的列表，但没有进行很好的格式化，而是简单的以逗号分割。列表的第一项是：
   TLS_RSA_WITH_AES_128_CBC_SHA
   第二项是：
   TLS_RSA_WITH_AES_256_CBC_SHA
   在列表中移动光标。将第一个128改为256，然后继续移动光标，将256改为128.（如果你不能编辑或输入，可以将其拷贝出来，粘贴到记事本中，编辑后在粘贴回来）。
6. 如果你想取消RC4和其他非AES算法，以便使用AES替代RC4，并且你知道你的浏览器是Beast免疫的，那么可在列表中移除RC4的项。 例如：TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, and SSL_CK_RC4_128_WITH_MD5
7. 也可改变其他的顺序，但要保证确实是在算法种类中做的改变。
8. 点击OK，关闭组策略编辑器，重启系统。

使用相同的方法，你可以移除不想使用的所有算法，以锁定Windows只使用AES或只使用AES256作为加密算法。

然而，对于基本家庭版和高级家庭版的用户而言，是没有“组策略编辑器”的（如果你从其他Windows中拷贝过来是无法运行的），进行这项改变是比较麻烦的。但是上述的设置都会体现在注册表中，因此可以直接更改注册表。我们这里不详细说明了，具体可以参看此链接。

如果你不确定你的Windows版本，可以尝试上述操作，看看gpedit.msc是否能打开一个对话框。

锁定你的Web站点（Apache）

如果你是一个web站点的所有者，并且你的站点使用了SSL，你可以“锁定”站点以便只支持AES256。这将去除终端用户的选择权--要么使用AES，要么不安全的连接（？）。这对于非常敏感的站点是很好的事情。然而，它的“危险”是你的一些用户可能使用的是不支持AES算法的浏览器（例如IE的一些旧版本），因此他们无法访问你的站点，除非更换浏览器。

要想将你的站点锁定为支持AES128或AES256（使用AES但不要求256是为了iPhone等设备上的浏览器可以工作），你可以在httpd.conf文件中添加如下内容：

SSLCipherSuite AES256-SHA:AES128-SHA

这也可以添加全局配置，在虚拟目录中，甚至是在你的.htaccess文件中（不太懂）。这会确保所有到你的站点的连接都使用了这些算法中的一个。需要保证将其添加到你站点的安全设置中，而不仅是不安全的站点区域（？）。更多信息参看这里。

一般而言，要为Apache进行高级别安全配置，你应该仅仅支持TLS v1.0+的协议和NIST推荐的算法。参看： what level of TLS is required for HIPAA.

结论

如果你有AES选项的话，它是使用SSL的正确姿势。只要你是用的计算机不是古董，它真的不会太多的影响速度和性能。如果你担心安全的话，我们强烈建议你使用启用了AES的浏览器和/或email客户端（如今大多数程序中都包括）。

注意SSL和TLS只保护在你和服务器之间传输的数据，当你收发email时，在发送者和接收者之间网络上传输的信息数据是不受保护的，无论你的SSL是多么好（译者注：也就是说SSL只是信道加密），更多信息请参考The Case for Email Security。解决方案是在SSL之外使用端到端的email加密方案，例如LuxSci的SecureLine（SecureLine保护信息内容，SSL保护你的用户名和口令）。

¹ 对于真实email程序的测试，我们通过在IMAP端口运行调试模式的openssl来进行的。这将会记录下客户端和服务端选择的密码算法。

类似博文:

• Are Export-Grade Encryption Options Needed Anymore?
• LuxSci Gets a Fresh Look
• Google Apps Users Beware – Your Web Browser May Not Work!
• What Level of SSL or TLS is Required by HIPAA?
• Master Password Encryption in FireFox and Thunderbird

---------------------------------------------------

[译]SSL/TLS真的被BEAST攻击攻破了吗？真实情况是怎样的？我应该做什么？ 

原文链接：https://luxsci.com/blog/is-ssltls-really-broken-by-the-beast-attack-what-is-the-real-story-what-should-i-do.html

原文发表时间：2011.9.21

本博文仅仅是上述原文的翻译，仅供研究参考，本人不对准确性作任何保证，侵立删，如有转载，需自行承担所有责任。如有翻译不准确的地方，欢迎指教。

更新：2015.1。SSL v3应该被关闭。RC4现在不再安全，因此不应再使用，即使是为了对抗BEAST攻击。LuxSci建议使用TLS v1.1+和NIST推荐算法，BEAST攻击现在也不再是一个很大的威胁了（即使在使用TLS v1.0的情况下）。

更新：2012.4。openssl v1.0.1已经发布，其支持TLS v1.1和v1.2，这会帮助缓解这种攻击。

根据一种最近发布的攻击机制（称为BEAST），SSL v3和TLS v1面临一种严重的威胁。这听起来动摇了安全的根基，带来了一定程度的恐慌。当人们看到这个问题时，会浮现出如下几个问题：

• 实际的影响是什么？
• 它有多严重？
• 我该如何保护自己？
• BEAST攻击是如何工作的？

在研究了这个问题后，我们对所发现的问题进行了概要，撰写了本文来回答这几个问题。

BEAST的实际影响是什么？

该问题可能影响浏览安全站点的人们，在某种条件下会导致窃听者能获取到你站点账户的访问权。它不会影响：

• 使用SSL/TLS的其他安全服务，例如emal使用的IMAP, POP或SMTP。
• 使用SSL安全的站点连接来发送数据（例如：使用secure web forms发送数据）（？不大懂）

它会影响：

• 你需要在安全站点上登录使用的帐号，例如PayPal, LuxSci, Gmail, Bank of America, Facebook等。

我浏览网站的什么时候会被攻击？

如果你使用的网络中，有恶意人员可以查看网络中所有的正常流量，并且可以截获并修改流量，那么他可能会危害你的安全网站浏览。

注意这并不包括和你使用同一个wifi或ISP的恶意人员，他们只能窃听到你的非安全连接，SSL对抗他们还是很有效的。但会包括如下场景：

• 本地网络管理员是个坏家伙
• 攻击者攻破了你的本地网络，获取到了服务器的控制权
• 你在一个对出入网络流量进行监控的国家（呵呵）

没有在那些国家并且使用可信网络的人们大可不必太过担心。这里的“可信”指的是：

• 你的本地ISP（例如：Comcast，AOL，Verizon等，类似国内的联通、电信）基本是可信的。我们对他们是深度信任的--如果他们想，他们可以有更为简单的方法来干坏事（例如通过将木马或病毒植入你的系统）。
• 你所在学校或公司的网络管理团队基本是可信的（这些家伙可以知道你在网络中做过的任何事情）。和ISP一样，他们如果想干坏事，有比TLS攻击更为简单且效果更好的方式。
• 政.府--你相信他们不会强迫ISP窃听你吗？即使他们会，大部分人也不用太过担心。

这种攻击发生在恶意人员想要窃听你的通信或在不知道先验知识的情况下访问你的帐号，他们可能（a）已经知道了你访问web站点的频率，或者（b）已经访问了足够多人的web流量，并且他们只想攻击非常流行的网站账户，例如Gmail，paypal或某些银行。

如果你对此比较担心，这是否是一个潜在的威胁取决于你所处的位置和你做了什么。

什么情况下我可能会被攻击成功？

简答来说，如果针对你发起了攻击，如果你做了如下的事情，可能会被攻击成功：

1. 你访问了任意非安全站点（http的而非https的），并且你的浏览器启用了JavaScript。
2. 你使用相同的浏览器访问因特网超过10分钟。
3. 然后你访问安全站点，而攻击者正想冒充你访问该站点。

注意，攻击者必须提前约10分钟猜测或者知道你将会访问那个安全站点。10分钟的间隔会随着攻击所使用的计算能力的增加而减少。

举个例子，我们假设攻击者想要窃听每个人的gmail帐号访问以便获取用户名、口令和其他敏感信息。

1. 你访问一个不安全的站点，例如http://google.com
2. 攻击者收集和处理访问https://gmail.com所需要的数据
3. 你继续上网一段时间
4. 你访问https://gmail.com以检查你的email
5. 攻击者可以使用已经收集的信息来访问你的Gmail帐号，就像他已经以你的身份登录一样。

我如何保护自己？

如果你对这种攻击比较在意，你可以通过如下方式来保护自己：

• 关闭你的浏览器（所有打开的窗口）
• 打开你的浏览器，直接访问安全的站点，而不要在之前访问不安全的站点

这种方式之所以凑效是因为这种攻击需要相同的浏览器session使用一段时间。关闭并重新打开浏览器可以使攻击者的准备工作失效。直接访问安全站点避免了攻击者的准备工作。

你可以通过很简单的方法达到这个目标：

1. 将你的主页设为一个安全页面，例如https://luxsci.com。然后你可以使用浏览器收藏夹来访问你想要去的安全站点。
2. 将你经常访问的安全站点书签放到桌面上，当你点击它是可以直接打开你想去的安全站点。
3. 在你的浏览器上禁用JavaScript，或者旨在可信的安全站点中启用。
4. 使用VPN。如果你将电脑连接到可信的网络（例如工作环境），这将会通过VPN发送所有安全的和不安全的web连接，从而避开了网络内的恶意人员查看和干扰你浏览的任何内容。

另外，如果攻击者不知道你的浏览习惯，并且你访问的站点不是非常流行，他们很难危害到你。例如：诸如gmail.com，facebook，bankofamerica.com等网站的用户量巨大，因此也容易成为攻击目标，比较小的网站如luxsci.com则一般不会。然而，如果攻击者知道你访问习惯，就会满盘皆输了。

BEAST攻击是如何工作的？

1. 当你访问不安全的站点，攻击者修改了返回的页面或返回的JavaScript，在其中添加了恶意的JavaScript。
2. 恶意的JavaScript在你的浏览器中自动执行（如果你启用了JavaScript的话）。
3. JavaScript打开一个安全的连接，例如到https://gmail.com
4. 攻击者将你的浏览器与https://gmail.com之间的流量与已知的通过JavaScript发送的流量进行对比，进行几分钟的计算，攻击者可以可以得到你安全会话的“初始向量”。
5. 这个信息允许攻击者访问在同一个浏览器会话中发往相同站点的后续安全认证cookies。
6. 这些cookies可以被攻击者“重放”，这样他们就拥有了你账户的全部访问权，就像以你的身份登录了一样。他们可以查看任何敏感信息，并且可以冒充你执行操作。

需要注意如下几点：

• 攻击者需要在你的浏览器执行JavaScript。
• 需要有一个不安全的web连接，以便攻击者能修改返回的内容。
• 攻击者需要猜测你即将访问的安全站点。
• 攻击者需要花费时间来收集和分析数据。
• 你必须随之连接并登录相同的站点，在相同的浏览器会话中（没有关闭并重新打开浏览器或使用不同的浏览器）。
• 攻击者必须在你的会话仍然活跃的时候才能执行恶意行为（如果你主动退出，也会把攻击者一同退出，希望攻击者没有更改你的口令）。

另外：

• 该攻击影响SSL v3和TLS v1.0
• 该攻击不影响TLS v1.1和TLS v1.2

那么，我可以只使用 “TLS v1.1″ 或“TLS v1.2″吗?

答案是“某些情况下是的”。

• 只有IE和Opera支持TLS v1.1或更高的版本。所有其他的浏览器（chrome、firefox、safari和大多数手机浏览器）都不支持这些最新的安全协议（译者注：该文章写于2011年，现在各浏览器的最新版本基本都支持了）。另外，即使IE支持，默认也是禁用的。另外启用它们也可能会影响一些常规的安全站点，例如如果你启用后一些站点不再工作了（译者注：这种情况发生在你只启用了TLS1.2，但服务器最高支持到TLS1.0的情况下，如果客户端同时也启用了TLS1.0，则不会有问题）。
• 大部分web服务器还不支持TLS v1.1或TLS v1.2，所以即使你的浏览器支持，你要访问的安全站点可能也不支持，例如bankofamerica.com, luxsci.com， mail.google.com等都不支持（译者注：仍旧是老黄历）。根据Opera的统计，只有0.25%的web服务器支持TLS v1.1或更新的版本。

为什么大多数服务器不支持TLS v1.1+？

• 标准的产品级SSL软件库，例如openssl，尚不支持TLS v1.1，因此大多数web站点无法启用。虽然正在开发中的openssl支持，但由于其性能、可靠性和bug等方面的原因，还无法包括在标准的操作系统分发库中。（译者注：仍旧是老黄历）
• 至今还没有对TLS v1.1和v1.2的强烈需求。

LuxSci正在与各个厂商（例如RedHat）联系，看是否可以将TLS v1.1的支持加入到现有的分发库中，以便使用者可以便利的升级。

其他可能的选择，包括使用其他的SSL系统或使用openssl尚未良好验证的最新版，都不是一个好的办法，因为这些可能需要多次的升级、大量的测试，升级时可能甚至可能需要停机。使用替代方式也意味着任何openssl后续安全升级的新特性都必须进行手工管理或依赖于尚待实现的升级机制，这就是替代方案没有大规模使用的原因，TLS v1.1-的版本具备标准的自动升级机制。

 

你可以检查通过使用SSLLabs web site来检查任何web站点的SSL功能以及其是否支持TLS v1.1或v1.2。

浏览器的升级情况如何？

浏览器厂商正在调查这个问题以确定会给用户带来多大的影响。我们希望他们发布一些浏览器升级包以减缓该攻击的影响程度，同时不需要服务器升级至TLS v1.1.虽然服务器升级长期来看是需要的，但至少不用这么着急。

微软给该问题的评级相当低；Firefox说即将开发一个修复程序；其他的TLS专家目前不太关注该问题。

其他一些信息

人们应该意识到安全是不断变化的。我们认为出了升级和实现软件修补外，还要考虑如下几点：

• 当任何可能的时候都使用SSL/TLS。不安全的站点对我们的浏览器和计算机是一个风险，因为我们无法控制任何恶意的第三方对我们浏览会话的注入，SSL和TLS客户保护我们远离这种威胁。
• 当访问安全的web站点时，最好新开一个浏览会话或已经浏览过安全的https站点。
• 将你的主页设为安全的站点，并且将其他的安全站点加入到收藏夹中。
• 针对普通的不安全浏览和安全浏览使用不同的浏览器。
• 保持你的软件、浏览器、操作系统、防病毒软件和其他组件更新到最新。

如果浏览器厂商发布了此问题的修补程序，威胁等级将显著降低。当前威胁程度也比较低，但是因为还很少有人会利用这个漏洞。

不过，以后相似的挟持不安全连接的攻击在以后很可能会呈现上升态势。将安全和不安全站点分别使用不同的浏览器是一个好习惯。

主动的安全习惯是一件好事情。

相似博文:

• Can S/MIME be trusted when SSL has had so many security issues?
• 256-bit AES Encryption for SSL and TLS: Maximal Security
• What Level of SSL or TLS is Required by HIPAA?
• SSL versus TLS – What’s the difference?
• Everything You Wanted to Know about SSL Certificates

---------------------------------------------

[译]BEAST还是一个威胁吗？

原文链接：https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat

原文发表时间：2013.9.10

本博文仅仅是上述原文的翻译，仅供研究参考，本人不对准确性作任何保证，侵立删，如有转载，需自行承担所有责任。如有翻译不准确的地方，欢迎指教。

昨天，我改变了 SSL Labs 的打分规则（译者注：SSL Labs是一个在线检测SSL站点安全性的网站），停止检测站点是否启用了服务端的BEAST缓解措施。这表示我们现在认为这种可以从客户端进行缓解，但是有一些事情你还是要了解的。

什么是BEAST？

TLS 1.0和更早版本的协议中有一个严重的漏洞：分组密码中在加密前用于混淆明文的初始化向量（IV）可以通过中间人攻击（MITM）预测到。IV是用来避免加密陷入定式，没有它们，你每次使用相同的密钥加密相同的分组时，你将得到相同的加密结果。这可不太好。一个聪明的攻击者可以通过如下三个步骤来猜测加密的原文是什么：1）猜测IV；2）看看加密结果是什么；3）改变加密原文（译者注：也就是“选择明文攻击”）。从技术的角度来看，攻击者并未解密任何数据，但是可以验证自己的猜测是否正确，但是如果没有足够多次的猜测，并不能发现任何明文信息。

这只是该问题的一个超级浓缩版本，如果你对详细情况感兴趣，建议您参看我之前写的一篇文章，并且参考那篇文章中推荐的链接。

因为猜测并不是非常有效的，因此在实践中BEAST攻击只能获取一小段数据。这听起来好像没什么卵用，但是我们使用的很多高价值的信息都是不大的数据段，例如：HTTP session cookie，认证凭证集（许多协议中都在用，而不仅仅是HTTP），基于URL的session token等等。因此，BEAST是一个很严重的问题。

缓解措施现状

BEAST是纯粹的客户端脆弱性。因为这种攻击已经被公开，许多主流的浏览器厂商都通过一种称为1/n-1 split的技术解决了这个问题。这种技术通过阻止攻击者猜测IV从而有效的从根本上解决了这个问题。

但是有一个平台拖了后腿 -- 苹果家的。我们对他们是怎么想的一无所知，因为他们没有就此问题进行过官方的说明。我的理解是Mountain Lion的发布版中会包含1/n-1 split，但是默认是禁用的。另外，据我所知，IOS中并未使用该防范技术。

因为苹果没有解决BEAST攻击，因此用户仍然潜在的面临着威胁。考虑到这个原因，今年年初，SSL Labs开始检测站点是否使用了服务端的缓解措施以对抗这种攻击。

 不幸的是，TLS1.0和更早期协议（当前使用协议的大多数）对抗BEAST唯一有效的方法是使用RC4算法。之所以说“不幸”，是因为我们刚开始服务端缓解措施检测后不久，一项关于RC4的研究发现这种算法比我们之前认为的更弱。这种脆弱性虽然不会立即带来危害，但很显然RC4算法正在走向不归路。

情况变得有些不妙，因为我们无法同时解决两个问题。但是因为两个问题大致可认为同样是低风险，最终的策略也是很明显的：RC4影响所有人，并且无法缓解；BEAST仅仅影响一部分人，并且不再有可利用的方法（希望吧）。另外，我们知道针对RC4的攻击正变得更为有效，针对BESAT的攻击似乎变得更少了。

BEAST还是一个威胁吗？

从目前的情况看，剩下的唯一工作就是证明利用BEAST的路径都被切断了。但是我们并没有有关这点的可信信息，因此我打算测试一些运行在脆弱性平台的浏览器，如果可能的话阅读它的源代码，并且尝试利用BEAST。

这项研究需要大量的精力和时间，主要是因为我不想只是运行现有的利用工具，我想完全理解这种攻击，并且发掘其他可能的攻击方法。Juliano和Thai（BEAST作者）对我的问题给了很多有用的回答。我曾走了一些弯路，一部分是因为现实的问题，一部分是因为我的错误。我认为BEAST在很长一段时间里仍旧是可利用的，因为我发现在BEAST里使用的同源策略绕过仍旧存在，这点令我很是惊讶。很显然，针对那个问题（译者注：应是指针对同源策略绕过的修复）的修复搞砸了。使用该漏洞，MITM仍能使用Java applet控制受害者的浏览器加密任意明文并发送到任意主机。

幸运的是，自从BEAST被公开之后，applet的运行机制已经发生了很多改变。例如：现在在运行applet前总会有一个警告。在我的测试中，Java插件无法获取HttpOnly的cookie，也无法在任何请求中发送或接收它。更为重要的是，由applet发出的HTTPS请求使用了Java的TLS协议栈，而不是宿主浏览器的。因为Java实现了1/n-1 split，因此BEAST无法发威。

结语

虽然SSL Labs对未实现服务端BEAST缓解措施的站点进行惩罚（打低分），但这个问题还会长期存在，因为还有大量的浏览器尚未进行修复。虽然我不认为现在这个问题已经被利用了，但是或许有我们不知道的一些攻击方式。Safari新添加的一项特性会使得该项漏洞再次可被利用，或者有时间进行测试的人可能会证明我是错的。由于这个原因，我们需要一个良好的安全保证，我们需要Safari默认的实现1/n-1 split。

另外，支持TLS1.1和1.2在现在及不远的未来并不能真正的解决BEAST，即使这些协议并不包含这种攻击所利用的IV预测漏洞。第一个问题当前网络还主要是依赖TLS1.0，在SSL Pulse检测的服务器中只有大约18%支持TLS1.2。因此，即使下一代的web浏览器都支持TLS1.2，服务完成升级仍旧需要一段时间。

还有第二个问题，所有主流浏览器都容易遭受协议降级攻击，主动的MITM可以模拟失败场景，迫使浏览器从TLS1.2回退至SSL3.0，从而利用IV预测漏洞。除非协议降级漏洞被修复，更新的协议仅仅对被动攻击者有效，对主动的攻击者则无效。

-------------------------------

[译]贵宾犬咬伤了TLS

原文链接：https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls

原文发表时间：2014.12.8

今天新发布的一个SSL/TLS问题可能会影响一些最流行的web站点，广泛使用的F5负载均衡设备也受到影响。已知有其他一些设备也受到了影响，可能一些SSL/TLS协议栈也受到了影响，我们在接下来的日子里会持续关注。

如果你不想阅读本文，可以这么做：1）使用SSL Labs对你的站点进行测试；2）如果存在脆弱性，打上你服务商提供的补丁包。这个问题很容易修复。

今天发布的攻击其实就是两个月（10月份）前发布的POODLE攻击，只不过转而攻击TLS。如果你还有印象，SSL 3对padding没有要求任何特定格式（除了最后1byte，长度部分），这将它自身向主动的网络攻击者进行了开放。然而，及时TLs对padding的格式进行了非常严格的限制，一些TLS的实现在解密后遗漏了对padding结构的检测。这种实现也容易遭受PODDLE攻击，即使是TLS。

这个问题的影响同PODDLE类似，但是更容易发起一些，因为它不需要首先将客户端降级至SSL 3，即使是TLS 1.2也可以发起攻击。主要的目标是浏览器，因为攻击者必须注入恶意JavaScript以发起攻击。一个成功的攻击需要使用大约256次请求以发现一个cookie字符，仅需要4096次请求就能获取一个16字符的cookie。这使得这种攻击方式相当实用化。

根据我们最新的SSL Pulse扫描（尚未发布），大约10%的服务器容易遭受针对TLS的POODLE攻击。

要向了解更多信息，请参看如下资源：

• Adam Langley – POODL又开咬了
• A10 – CVE-2014-8730安全公告(PDF)
• Checkpoint – Check Point对TLS 1.x padding脆弱性的回应
• Cisco – SSL-TLS Implementations Cipher Block Chaining Padding Information Disclosure Vulnerability
• F5 – SOL15882: TLS1.x padding vulnerability CVE-2014-8730
• IBM – Security Bulletin: TLS padding vulnerability affects IBM Cognos Business Intelligence (CVE-2014-8730)
• IBM – Security Bulletin: TLS padding vulnerability affects IBM Cognos Metrics Manager (CVE-2014-8730)
• IBM – Security Bulletin: TLS padding vulnerability affects IBM® DB2® LUW (CVE-2014-8730)
• IBM – Security Bulletin: TLS padding vulnerability affects IBM HTTP Server (CVE-2014-8730)
• IBM – Security Bulletin: TLS padding vulnerability affects Tivoli Access Manager for e-business and IBM Security Access Manager for Web (CVE-2014-8730)
• Juniper – Connect Secure (SSL VPN): How to mitigate any potential risks from the ‘Poodle’ (TLS Variant) vulnerability (CVE-2014-9366)