有谁知道这东西是什么算法加密后的？ (200分)

贷苑惩酵誉#荚挥涩.36&蹬地吻·5/墩艺#桐长刃潍#揩透蹬渍燃断砷帜#守鬃厦陈·厦陈渭帜；厦陈＜醒漱；3醒＜踞政闻；1/5梨秘＜鬃替；痕替·6/傈幽#叉褥鳖蛤#暗纽－咱政闻罪呼令岂壹醒吹僵壹各6醒÷5裂蹬恐鳖

看不出来嘛
只有密文的话想解密太难了：）

你应该说的详细一些！

有点相机构化数据结构

改天我把明文和密文都给大家贴出来，我想各类加密算法的输出有一定的样子，如果那位用过，看看它的形式应该可以说个大致吧

一般加密算法都用DES,RSA
你可以选一段名文，用这些算法试试
一般用公钥加密的话，你还是看不出来使用什么加的迷，因为还有私钥
而且，加密算法一般都是按块加密，这样好像很难看出什么东西

呵呵，我分析了一下，除非你的明文太特殊了，否则能够得到这个结果的加密算法应该不
复杂才对。
ps: 建议将加密后的结果以十六进制的形式贴出来，因为怕将乱码直接贴在HTML上会有信息
丢失。
eg:
5C 31 2F 55 66 74 75 51 70 6A 6F 75 4A 6F 67 70
5E 55 7A 71 66 3E 4E 58 70 73 65 51 70 6A 6F 75
...

感谢creation-zy的关注，我准备一下，今晚按你的想法贴出来，并有明文对照！

显示HEX的我还是没搞出来，给creation-zy发了邮件附件

邮件已收到，我刚才看了一下，似乎 rtfrtf 是 atporrtf.txt 的加密结果，不过我发现
这两个文件的长度不一致——不知是不是您在atporrtf.txt的第一行加了一个换行？
在我将atporrtf.txt的头两个字节忽略后，对它们进行按字节相减运算，得到了一个新的
文件——哈哈！这个文件的内容不是00就是01这说明密文和明文的每个字节要么相同，要么
只相差1！下面就是明文以及 密文-明文 的Hex显示值：
明文：
31 2E D4 DA D2 B3 C3 E6 B5 C4 B5 DA D2 BB D0 D0
BC D3 C8 EB CD BC C6 AC 75 73 74 63 7A 69 31 2E
6A 70 65 67 2C D6 B8 B6 A8 C6 E4 B8 DF B6 C8 CE
AA 39 30 CF F3 CB D8 A3 AC BF ED B6 C8 CE AA 36
30 30 CF F3 CB D8 A3 BB 0D 0A 32 2E BD AB D2 B3
C3 E6 CA F4 D0 D4 D6 D0 B5 C4 B1 EA CC E2 B8 C4
CE AA A1 B0 D6 D0 B9 FA BF C6 D1 A7 BC BC CA F5
B4 F3 D1 A7 A1 B1 A3 BB 0D 0A 33 2E BD AB CE C4
B1 BE A1 B0 BD F0 D5 AF C2 B7 39 36 BA C5 A3 AC
BA CF B7 CA A3 AC B0 B2 BB D5 A3 AC D6 D0 BB AA
C8 CB C3 F1 B9 B2 BA CD B9 FA A1 B1 B5 C4 D1 D5
C9 AB B8 C4 CE AA C7 B3 C0 B6 C9 AB A3 BB 0D 0A
34 2E BD AB D2 B3 C3 E6 D7 EE CF C2 B7 BD B5 C4
B1 ED B8 F1 CA F4 D0 D4 B8 C4 CE AA A3 BA B6 D4
C6 EB B7 BD CA BD CE AA CB AE C6 BD BE D3 D6 D0
A3 AC B5 A5 D4 AA B8 F1 B1 DF BE E0 CE AA 34 A3
AC B5 A5 D4 AA B8 F1 BC E4 BE E0 CE AA 35 A3 AC
B1 DF BF F2 B4 D6 CF B8 CE AA 32 A1 A3
密文-明文：
01 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
00 01 00 01 00 01 00 01 01 01 01 01 01 01 01 01
01 01 01 01 01 00 01 00 01 00 01 00 01 00 01 00
01 01 01 00 01 00 01 00 01 00 01 00 01 00 01 01
01 01 00 01 00 01 00 01 01 01 01 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
00 01 00 01 00 01 00 01 01 01 01 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 01 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 00 01 00 01 01 01
01 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
00 01 00 01 00 01 00 01 00 01 00 01 00 01 01 00
01 00 01 00 01 00 01 00 01 00 01 00 01 01 00 01
00 01 00 01 00 01 00 01 00 01 01 00 01
至于什么地方是00，什么地方是01，看起来似乎有一点规律，但又不是很有规律，于是我
进行了猜测——应该是和明文的值有关。随后的分析证实了我的想法：
将明文看成一个Byte数组，加密顺序为正序。当遇到的明文的值小于128时，密文等于明
文+1；反之，当明文的值大于等于128时，这第一个字符的密文和明文相同，而紧跟着的后
一个字符的密文则等于明文+1。
对应的算法代码为:
function Encode(Str:String):String;
var
i,n:Integer;
b:Boolean;
begin
n:=Length(Str);
SetLength(Result,n);
b:=false;
for i:=1 to ndo
begin
Result:=Str;
if b then
b:=false
else
b:=(Byte(Result) and $80)>0;
if not b then
Inc(Result);
end;
end;

——呵呵，够简单吧

ps:
我的所有分析都是用自编工具 FileTool 完成的（包括Hex显示、文件相减），下载地址为：
http://xianjun.vicp.net/temp/以前的文件/FileTool.zip
http://www24.brinkster.com/creationzy/download.asp?id=1
)

>>不知是不是您在atporrtf.txt的第一行加了一个换行？
这个都被想出来[]