Keep it simple, stupid

加密算法:

加密算法一般分为对称加密和和非对称加密，对称加密是指加密与解密使用的是同一密钥，而非对称加密加密解密使用不同的密钥，一般把两个密钥分别称为公钥和私钥。

对称加密算法又分为序列密码算法和分组密码算法，从名字可以看出，序列密码算法在加密的时候每次只加密一个字节，而分组加密是把要加密的内容分为一块一块，例如16个字节，每次对这样一块数据进行加密。

典型的序列密码算法是RC4(由Ron Rivest发明，就是那个RSA的R)，RC4是RSA公司的一种专有密码算法，在1994年的时候有人匿名发出了一份RC4的加密算法的代码，并被证明与RSA公司的RC4是兼容的。RC4是一种密钥长度可变的算法，其密钥长度可以在8~2048位之间。不管密钥有多长，都被扩展为一张固定尺寸的内部状态表，因此不论使用多长的密钥，该算法的运算速度都是一样快。

序列密码算法得到的密文是与明文一一对应的，因此为了防止被修改一般配合一种摘要算法来使用。

分组密码算法每次只能地固定的长度数据进行加密，例如16个字节，如果想要加密更大的数据，得使用ECB(Electronic Codebook)或者CBC(Cipher Block Chaining)模式。ECB只是简单的把消息分割成固定的16个字节，并使用加密算法对各块进行加密，这种方式有着明显的不足，例如两段很相似的明文，另密后也会产生很类似的密码，这会暴露给攻击者很多信息。CBC解决了这个问题，对每个明文分组的加密依赖于前一密文分组的密文。这是通过在加密前会使用前一个密文分组与明文进行异或来实现。这个时候第一个文明分组会与一个叫做IV(初始化向量)的随机分组进行异或。

DES是应用最为广泛的对称式加密算法，它是一种具有56位密钥的64位分组，意思就是以8字节大小的分组进行加密，密钥空间为56位，DES密钥的实际是64位长，但是每个字节的低位用来做奇偶校验。由于计算机速度的提高，DES已经被认为是不安全的了，毕竟密钥太短。在这种情况下3DES算法就出现了，3DES算法一般使用加密-解密-加密(EDE)的模式。

RC2同样是R发明的分组密码，它采用一种经过变形的变长密码，它还具有一种可变的有效密钥长度。

AES至少有128位的分组大小，可以用128、192、256位的密钥长度。

非对称加密：

最出名的算法应该是RSA了，RSA的理论基础很简单，而算法的安全性基于一个数学难题：“对一个大素数进行因数分解”。

Diffie-Hellman(DH)是首个公开发表的公钥加密算法(RSA一开始是有专利的)，一般用于密钥磋商，而RSA用于密钥交换。

摘要算法:

摘要算法比较简单，从设计的角度来看，所有的摘要算法都非常的相似，唯一的区别就是输出尺寸的不同。两种最流行的算法为MD5、SHA-1。由于MD5的输出长度只有128位，而且存在了相关的破解方法，所以一般在PKI中推荐使用SHA-1。

Comments

dream: 不错，我以前也学习过安全方面的知识，继续发表相关的文章吧，我关注啊 :) 不过一直对PKI这一系统不太理解，另外 “摘要算法:“的 下文怎么没有了？

可可熊: 公司在做安全相关的东西么。

alex: http://songshuhui.net/archives/12755.html

草儿: 当年学习的网络安全都快被我扔完了，没想到你还在研究。

hawkli: MD5虽然说已经有了王小云算法论文，但是在商业化环境中，现在还是安全的。我不认为现在已经达到了商业化可破解的程度，业界还是有大量的应用存在。我相信至少MD5还有5年以上的商业生命周期，之后才会逐渐由其他加密算法渐渐替代。

先给大家看一个关于网银与USB-KEY的科普教程：

http://apex.ncksoft.com/archives/tag/usb-key

写得还不错，看完后你对目前网银的安全模式应该有个大概的了解。

目前公认最安全的网银模式就是使用2代U-KEY，就是在普通的USB-KEY的基础上增加一个确认按钮和LCD显示屏，这样可以极大的确保每一笔交易是经过你的确认。目前工行已经推出了二代U-KEY。

这里解释下二代KEY出现的背景，由于我们平时使用的电脑是“不可信环境”(在病毒、木马泛滥的年代，大部分人的电脑都可以被被木马随意操作)，所以我们不能相信自己的鼠标，比如我们点了下鼠标，做了一笔转帐交易，木马很可能帮你再点一次，这个时候就得在U-KEY上加一个确认按钮，防止木马偷偷做交易；我们也不能相信自己的眼睛，例如本来打算用1000块钱买个手机，结果木马把这个数字在发往U-KEY时改成了1W，而在屏幕上显示的仍然是1000，我们很无辜。这个时候你得在U-KEY上确认下我刚才是不是花了1000块去买那个手机。

U-KEY其实已经是一台完整的计算机了，根据冯·诺依曼原理，输入设备(LCD显示，按钮)、存储设备(16-32K)、运算器、控制器(智能卡CPU)，而且U-KEY还有自己的操作系统COS(Card Operating System)。由于平台的特殊性我们可以假定不会有木马进入这个U-KEY，因为所有针对U-KEY的操作都要通过COS对外提供的接口来完成，而且不同厂家的COS一般是不同的。这个时候U-KEY是一个“可信环境”，所以我们可以确保在按下“确认”按钮的时候U-KEY一定是对LCD上显示的交易进行了签名，签名算法可以确保该签名后的数据无法被修改。

最近公司在做U-KEY，不过不是传统意义上的USB-KEY，所以得和SSL,openssl，CSP，PKI，X509等这些安全、加密、证书相关的东西打交道。

Comments

Kermit Mei: 最近发现在你的blog上坐沙发越来越不容易了……

cocobear: 很容易吧，你看现在不就是吗？ 好久没怎么写东西了。

可可熊: U-KEY都是基于MS的CSP架构，所以…… 这一点是由国内的银行决定的，无法改变的。

Silence: 很强大啊这个 blog要多更新啊

草儿: 看到U-KEY我总会想到Linux，然后想到Linux上好像没用过U-KEY，可能是和普及程度有关吧，至少对大众来说用的都是Windows系列。

SSL是用于网络安全传输的协议，在TCP之上，HTTP之下。以前对标题里面这几个有点分不清楚，今天花了点时间整理下概念。

SSL为(Secure Sockets Layer)的缩写，是网景公司为网络安全传输制定的一套标准，SSL1.0没有公开发布过，所以SSL1.0可以无视之。SSL2.0在1995年发布，不过因为有很多的安全漏洞，所以SSL3.0很快在1996年就出现了。不过主流的浏览器在很长的一段时间内都在支持SSL2.0,IE6默认是支持SSL2.0的(IE7中SSL2.0被禁用了)，Firefox2以后禁用了SSl2.0,Opera在8.5以后也禁用了SSL2.0。

IETF在1999年的时候以SSL3.0为基础，制定了TLS(Transport Layer Security) 1.0，RFC2246对TLS进行了详细的描述。TLS 1.0在框架上完全使用SSL3.0，只是在一些细节上有差异，比如采用的算法集，随机函数的产生，这里有一篇文章对TLS与SSL3.0区别进行了详细的描述。
由于TLS基本上是对SSL3.0的补充，因此在很多地方SSL3.0 TLS这两个名词被混合使用。

TLS也在更新，不过变化不大，RFC4346对TLS 1.1进行了详细描述。
TLS最新版本为1.2，相关的RFC为RFC5246。

目前国内网站使用的HTTPS其本上都是基于SSL3.0的。

以下是wireshark抓包一个SSL3.0的通信过程：

client  ------------->server [Client Hello]
server ------------>client   [Server Hello]
server ------------>client   [Certificate]
client  ------------->server  [Client Key Exchange , Change Cipher Spec, Encrypted Handshake Message
server ------------->client  [Change Cipher Spec, Encrypted Handshake Message
client -------------->server [Application Data]

Comments

可可熊: 最近在做PKI相关的东西，公司的事。

草儿: 怎么从pythunder突然转向SSL了？难道……

Kermit: 你最近在做那方面的工作？感觉你blog上很多东西的跨度确实有点大……

rhlei: DP做的东西面真广~~哈哈

可可熊: 不止这些。。。

首先确认apache支持mod_ssl， openssl也正确安装。

Fedora 8中apache关于ssl的配置文件在/etc/httpd/conf.d/ssl.conf文件中，使用SSLEngine on选项来开启HTTPS的支持，apache默认会使用一个自带的localhost 的证书来进行HTTPS连接。

接下来我们使用openssl生成自己的证书进行HTTPS连接：

mkdir /etc/httpd/conf.d/ssl.crt/
cd /etc/httpd/conf.d/ssl.crt

(1)
生成服务器的私钥：
openssl rsa -in server.key -out server.key

openssl req -new -key server.key -out server.csr

生成Certificate Signing Request（CSR）,生成的csr文件交给CA签名后形成服务端自己的证书.屏幕上将有提示,依照其指示一步一步输入要求的个人信息即可.

(2)
对客户端也使用同样的方式：
openssl genrsa -out client.key 1024
openssl req -new -key client.key -out client.csr

(3)
生成CA中心的私钥：
openssl genrsa -out ca.key 1024
生成X509格式的CA证书：
openssl req -new -x509 -keyout ca.key -out ca.crt

(4)
用生成的CA的证书为刚才生成的server.csr,client.csr文件签名:
mkdir ../../CA
mkdir ../../CA/newcerts
touch ../../CA/serial
cat “01” > ../../CA/serial
touch ../../CA/index.txt
openssl ca -in server.csr -out server.crt -cert ca.crt -keyfile ca.key
openssl ca -in client.csr -out client.crt -cert ca.crt -keyfile ca.key

(5)
生成浏览器使用的PFX格式的证书：
openssl pkcs12 -export -in client.crt -inkey client.key -out client.pfx
把ca.crt安装到信任的机构，client.pfx安装或安装到个人证书位置

(6)
编辑ssl.conf配置文件，修改证书相关的地方：
SSLCertificateFile /etc/httpd/conf.d/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf.d/ssl.crt/server.key
SSLCACertificateFile /etc/httpd/conf.d/ssl.crt/ca.crt

Comments

kaiixin: 我日 第一个命令就不能执行 麻烦写清楚点

前几天在Python中文件邮件列表里看到讨论使用Python实现迅雷，后来又在Ubuntu论坛看到一个贴子，实现了获取迅雷服务器上的侯选资源（不是开源的）。突然就对这个迅雷协议很感兴趣，在别人分析的基础上用Python写了个小工具，与Ubuntu论坛上那个作用是一样的，获取迅雷服务器上的侯选资源。

迅雷有多个资源服务器，有的资源服务器返回完全一样，有的返回某些一样，这样可以指定多个服务器，获取更多的资源，同时也可以防止某个服务器不能正常响应。

用webpy写了个演示面面：
http://cocobear.github.io/demo/pythunder/?url=http://3.duote.com/xunleidt.exe

不知道开源了会不会产生麻烦？

———————————解释下标题——————————
前几天拿U盘做产量的时候没把代码备份出来，所以原本已经写好了今天又写了一遍，幸好代码很短:-)

Comments

zay: 你发的用不了 不知道是不是没有编译过的问题？

kongove: 给我邮箱发一封，学习一下。 下面我也得深入python了。

edikud: 代码就是看不懂。。。。

edikud: 加了个友情链接

可可熊: 楼上指什么代码看不懂？

edikud: PyFetion。。。

草儿: 可以复制，我刚试了。但有时候似乎不好使。Firefox下可以。 本文来源于可可熊的窝 http://cocobear.github.io , 原文地址： http://cocobear.github.io/2009/05/04/rewrite-pythunder/ 靠，我在IE8下复制了一句你就给我自动加了那么多。

zay: bear 我也想要一份……

damon: 又有啥好东西哦！

草儿: 已经有两次同样的错误了，期待你第三次掉进那条河……

草儿: 对了，你的页面内容是不是不能复制？

可可熊: 可以复制，我刚试了。但有时候似乎不好使。Firefox下可以。

Kermit: 排队——我也要一份…… BTW： “不知道开源了会不会产生麻烦？”——我觉得只要你没有反汇编xunlei的代码，只是通过抓包分析得到的的东西，不管开源与否，应该都不会有问题吧。

可可熊: 我指的是公开后用的人多了，很快就会被迅雷封掉。

Kermit: 这个是肯定的喽，没见过哪个不被封的……除了那些封不住的。

zay: bear同学 不知道 你能不能发那个*.pyc的文件给我呢？源代码没有没关系 我想在我的服务器上面使用

zay: liangkazhe@gmail.com 谢谢你了

cocobear: 还没完善，等整完善了给你。

可可熊: 你的邮箱。

ysjdx: 不知道可不可以把*.pyc文件给我呢？我想用，谢谢了！:)

ysjdx: ysjdxcn@gmail.com :)

tocer: 非常感谢。有时候要下载某个失效的链接，非这个东西不可:(

tocer: 能否给我一个，就算pyc也成，我自己拿着玩

zidane: 迅雷真是让人又爱又恨

可可熊: http://code.google.com/p/pytool/

brooklyn: 同求代码……保证不泄漏出去。