在看 php 的 mcrypt 加密，想使用对称算法，解决小块内容（比如 url、post）网上传输的安全性。即加密、解密用同一个密码。官方文档有个非常完整的演示功能的例子，大概顺序是：
- 打开 module
- 生成 IV
- 得到 key/密钥/密码
- 初始化（引擎？）
- 进行加密操作
- 关闭（引擎？）
- 重新初始化（引擎？）
- 进行解密操作
- 关闭（引擎？）
- 关闭 module
加密、解密放在了一个代码片段中，大概是想说，加、解密就那一句代码不同而已。
按照这个理解，为了使用方便，我把加、解密分解成了2个函数，内容都和例子差不多，不会有错。但一运行，不管用哪种加密算法，都会出现奇怪的解密后与原文不一致的错误。还不是完全不一致，后面大半段内容都是正确的，比如原文是包含 a-z 26个字母的字符串，运行结果如下：
$ ./mcrypt.php
Encrypt:
M~<5¶¤Jw^TÝ×. ÃV¯
Decrypt:
Âò¹ÁIijklmnopqrstuvwxyz
好一通找原因，最后在支持算法列表页面中找到这么一句：The IV must be unique and must be the same when decrypting/encrypting.加、解密时所使用的 IV 必须相同。
昏，例子代码中 IV 是使用随机数生成的，分成2个函数之后，加、解密操作生成的 IV 肯定不一样，这就是解密失败的原因。mcrypt_create_iv() 函数文档页面的 user notes 中有位 Chris 还对 IV 纠正了一些错误观点。
综上，正确解密需要将 IV 与密文一同存储、传递。而我的需求比较简单，就没有必要这么作，反正 IV 也不需要保密，所以直接用 key 的 sha1 值的片断，比如前8位（与 git 版本号简写类似）作为 IV，对安全性影响不大，应该是可以接受的。
问题解决，收工，有和我一样吃过亏的同学么？
Related posts
开始之前，首先要澄清两个问题：第一，支持开源，不等于反对代码加密；第二，如果把不属于自己的东西（比如公司的）拿去开源，就更加不应该了。
以前知道的，PHP代码的加密都是用Zend的encoder，这东西不但是商业软件，好像还暴出过能够被破解的问题，所以就找到了替代的方案────php_screw，一个日本人开发的东东。
php_screw非常小巧，没有仔细看过它的算法，但从说明文档中看，可以自行更改SEED，然后自行编译so和可执行档。如果够牛的话，甚至可以自己去更改算法。不管怎样，对于我们这些“普通人”来说，这种加密应该就够了吧，如果真想滴水不漏，那还是不要公开的好，虽然作者说的并不是很容易就破解，但指不定哪儿有牛群呢不是么？
安装的环境需要：PHP5.x，zlib开启，autoconf，automake已安装。
测试环境：Ubuntu 8.04 hardy, PHP 5.2.3。
1、 解压，更改my_screw.h，里面的几个数字就是SEED，相当于密码，可以随意更改、增加，并且数字的多少不影响解密的速度。
2、编译so文件：
$ phpize
$ ./configure
$ make
如果出现这样的错误，那是因为autoconf没有安装：
$ make
make: *** No targets specified and no makefile found. Stop.
3、安装so文件，编译好的文件在modules目录下，将其拷贝到php extension存放的位置，比如/usr/lib/php5/20060613+lfs下，然后在php.ini中增加：
extension = php_screw.so
4、编译用来加密文件的可执行文件：
$ cd tools
$ make
tools目录下新生成的screw就是了，放到$PATH中就可以调用了，比如要加密一个文件：
$ screw a.php
Success Crypting(a.php)
加密后的a.php执行正常，同时screw还会把原来没有加密的文件改名为.screw文件作为备份。
Update @ 2008-09-01
加密之后，还有个小问题，用require或include引用放在include_path下的加密代码时，会当做明文引过来，解决方法有两种：
- 使用绝对路径引用放在include_path下的加密内容，如果是自己的主机，肯定没问题的；
- 使用相对路径来引用，比如在本项目的子目录内，这样也是没问题的。
Related posts
