大家讨论一下这个加密算法的安全性（顶一下吧！）。 ( 积分: 200 )

关键字：
1 NRS － N个字节（N>=128）随机串，实时随机生成的
2 NRS_ENC － 用DES加密后的串。
3 KEY8B － 8字节私钥
加密方法：
第一步：
NRS ---|
DES---> NRS_ENC
KEY8B ---|
第二步：
NRS_ENC--|
XOR---> 密文
明文 ----|
第三步：
输出加密数据流： NRS_ENC + 密文

补充一下，该算法的目的：
能以较快的速度加密，并达到DES加密整个数据流的效果（完全DES加密速度很慢）。
已知缺点：
必须在输出流中加上NRS_ENC。
欢迎大家踊跃参与讨论！分析一下安全性、优缺点。
－－－－－－－－
解密过程：
第一步：
NRS_ENC ---|
DES---> NRS
KEY8B -----|
第二步：
NRS -------|
XOR ---> 明文
密文 ------|

关于DES以及XOR的评述，可以看下面这个帖子：
http://www.delphibbs.com/delphibbs/dispq.asp?lid=3697044
XOR是简单对称加密算法，楼主的算法实际上很简单，为了解密，解密者必须知道NRS_ENC
的全部内容，或者，知道NRS以及KEY8B信息以便生成用于解密的NRS_ENC。
加密算法的好坏主要看几个方面——加解密的速度、抗攻击的能力以及对加解密密钥的要
求（因为解密方要想解密，就必须以某种途经从加密方获得解密用的密钥——而攻击者完全
可能在这个途径上下手）。
DES的主要问题还不在于快慢，而是密钥空间不够大——这年头，128bit加密才可以顶个
几年而不被暴力破解。

在实际应用中，可以将DES换成密钥空间足够长的对称加密算法。
这样除了知道Key的外，其他别无办法。
我在加密算法方面是外面，不过我想这个加密方法是简单而实用的。

楼主的算法可以用来加解密——这是毫无问题的。但是既然要探讨它的安全性，就必须面
对反算密钥这个问题。楼主既然提到了“在输出流中加上NRS_ENC”，那么，如果被加密的
信息如果长度超过了NRS_ENC很多倍（例如一个长达几M的Exe文件），就不可避免的要对不
同的区域使用同一个密钥——而这就是最要命的地方。以Exe文件为例，它的头部上千个字
节的文件头中的很多信息都是基本固定的，破解者可以根据头部的信息就反推出用于加密的
NRS，得到了NRS，再破解剩下的部分就不费吹灰之力了。要想让NRS不重复，就只能增加
NRS_ENC的长度——要想100%不重复，NRS_ENC的长度就要与被加密的明文长度相等。
楼主的思路还是不错的——利用附加的随机信息，可以达到对相同的明文加密后产生不同
的结果的效果，只是这种附加信息的附加方式以及加密方式都要尽可能的抗攻击才会有实用
价值。

首先感谢creation-zy大哥如此耐心指点。
这个算法是我为了加密普通文件设计的，对安全性方面的要求不太苛刻。
我以前以对加密方面没什么研究，借此机会多学习一下。
在重复应用相同数据进行XOR的问题的确是个大问题，写算法时我也想到了这一点。
不知道是否可以通过某种“递进”运算的方式来弥补这个不足。