请教如何判断加密算法

[standin000]

它的密钥是64个字节，B76113C2ED7261B0048215D0A63B993403898AB9D4510655BD32C7394D9B6F26，不像是DES加密。

密文是
awEAAJ9oCrIr0VSspAgCg+DOawXWd/c8YSaBWAzO5NLXg+xKH1weU4I76CySb5uo32g7BxBFLkz2IYamtGc5cZ2Gk/SyWDDtpPgapaTUEOwugOEe3N8x072SuHsGqLvMZPNntTe5r+LyGBidh\
STqnGGPXPyCA09Kx3F7ANDVQu/946E5RMp+E2AWX4rKaXfsGjzVVIRcjcTw0lECuoiUOq7N93tphgG/R/oSz2VqH4UqyiKaOEMNOGRPbT509mJJ8lqKxkgJKxjl8JoWkE0aeEsWY2NFM4hWxG\
XtAwJMwur2lLd/gfh2a5E2vo6KRm6fkDuh4rfkAYDHTsb+0xLK/gPGw64pUQ9wki1SxuajTSSXwrgl20qpJhUpcDkTPUMxbE2kOiFHK5aWtHEkiAWvM1V26RvZLaE5YvtkMDI2kw2pUZY5wnQ\
900d73nHWO5r0NaH17dW0+aHXK+z+1WTEAFxjZMDhmwS6IZrWK8eiX3UHRxaV3kmaxA==


结尾有==，我以为是base64加密，但试过不是。

请教各位有什么线索吗？

我想我有点明白了。这个算法其实是。

Alice准备了一份合同M；
Alice生成一个随机数；
Alice选用该随机数作为密钥对合同M进行对称加密，生成密文合同；
Alice选用Bob公钥对随机数进行非对称加密，生成信封；
Alice将密文合同和信封一起发送给Bob；
Bob接受Alice发送的密文合同和信封；
Bob选用自己的私钥对信封进行解密，得到对称密钥(随机数)；
Bob使用该对称密钥(随机数)对密文合同进行解密，得到合同M。

我们只能看到信封和密文，密钥是被非对称加密了的，这样确实无解了！

[auser]

实现过DES和AES.

DES真实密钥真有56位，不说了。

AES密钥长度128、192、256位，换算成字节分别是16、24、32个，如果一个字符算一个字节，分别是16、24、32个字符。通常你的密码连16都达不到。这时，要么把你的密码直接当成密钥用来加密，不够补零，要么就使用key stretching（自行查阅维基百科）。

我理解的正常情况下，密文不可能全部是可打印的ASCII字符。所以这里的密文很可能是转换过的（很可能有多次）。

通常对称加密的输出是“纯密文”，不包括加密参数（比如算法、密钥长度）的任何信息。如果你要做一个加密软件，那么就需要设计一个协议，并把它作为加密后文件的头（或其它）部分。协议里可能记录采用的加密算法、密钥长度、块加密模式、初始化向量（IV）等解密时必须的信息。

综上，无解。

[duzhe0]

1.你给的密钥应该是256位的2进制数据的hex值， 不是64个字符
2.密文应该是base64的

[dong3580]

你这个有点像是RSA加密的嘛，不过位数怎怎么长,结尾一个==，无解。
eOUP+q78QFyELsBHs6jpvr9EtDO+Dzdev2qBiElSzmAPImqSpSs5PQfqUpYMFMbNXiGH09ppJM/1+qNH0AXd6RCE5FWr/dBXyoDhAbkQyFXn3kLPGkFbfr5yM+XgryrAmS0b7aGmCJwxUNBhmIzFEZNDyaVwb0KTaiMBQNFcLk4=

[standin000]

@duzhe0 那密钥是32个字节，但base64加密是不需要密钥的，这个怎么解释？

[standin000]

@auser
@dong3580 都是觉得密钥太长了吗？

[duzhe0]

@standin000 多次加密，最后一次是base64

[oott123]

base64 是编码，不是加密。
由于你通过各种算法加密出来的可能是一堆二进制数据，不便于传输或者怎样，所以加密完之后做个 base64 。

回到算法问题，我认为没有可以判断的方法。

[xierch]

考虑到原文应当是有意义的数据而非随机数据
应该还是有可能推测出加密算法的（？）

[auser]

@standin000 这个密钥长度256位，属于正常长度，不是“太长”，但对AES来说已经是（我理解中能接触到的）最强的加密强度了。

AES算法的原型是Rijndael算法（相当于我要制定一个加密标准A，然后有a、b、c等各路算法投稿，最后算法a成为了加密标准A），它支持的相关参数选项要比AES多。

再多说一点吧：例如AES加密，每次加密的输入必须是128位，如果不足128位（通常是最后一组数据），需要用到填充算法，这个可以搜索维基百科中密码学下的Padding词条。你能保证原文（明文）长度一定是16字节的整数倍吗？

因此，你这个问题真的是无解的，不用想了。当然，假设问题成立，各个组合试一试总会有正确答案。即便如此，你知道了加密算法，比如是AES，你照样需要花费非常多的时间去暴力破解（前提是它加密用到了CBC、IV Padding之类的东东，是真正的加密）。

（其它对称加密算法不清楚，不知道哪些支持密钥长度是256位的）

[raptium]

密文看起来是 base64 编码的
解码后看到开头 4 个 byte 像是“信息长度”
其他就不知道了

[standin000]

@auser 我有点不理解，已经知道密钥和密文，又知道加密算法的话，当然可以解密和再加密了。

@raptium 你是用base64解码后的前4个byte吗？有点不像长度了。

[raptium]

@standin000 挺像长度的啊 才差了十几个 byte

[auser]

@standin000 AES是块加密，自行搜索块加密。每次加密输入是128位，对应128位输出。假如你要加密00001111（二进制串），你不填充到128位怎么加密？我之前实现用的是pkcs7. 其它还有很多填充标准。题外话，MD5算法也要用填充，用的是位填充，貌似必须补齐512位，记不清了。

为了防止相同块加密后的相同输出，通常会用到初始化向量和块加密工作模式。你潜意识里根本没有这些概念，以为加密只有这些就行了是不对的。

里边细节问题很多。想知道的话自己搜吧。
EOF

[lsylsy2]

其实我倒觉得这个问题是可解的，如果这是完整的密文（没有CBC之类）……
加密算法构建的目的基本都是“知道算法，知道密文，不知道密钥的情况下无法获取明文”，而不是知道密文密钥不知道算法。
考虑写个程序，试验下各种算法吧，费点事而且不一定有结果就是了

[ccidcce32167]

说下我的进展：我刚才查了一下base64的信息 base64编码表里有 [/] 但是是没有 [\] 的。所以密文里有 [\] 应该是没道理的，于是我把密文用 [\] 拆成三段分别用base64去解码，不幸的是第一段解出来依然是乱码，第二段解出来是
I: c? ^45PxNQ2 ] 5U! #q<4@% }aoZJ N O=| J9|& F L
第三段解出来是
^0$.iKw f kf +~@ to1,<l: ",nj4I|+]aR 33 C rikG HZ5Wn /C #i0 c'C4w cCZ ^[O rVL@ 6L K bz%Ptqi]@
就到这了。。。

[zoho]

@ccidcce32167 不是有三个 \ 么？应该拆成四段啊。

[xurubin]

看密文的熵还是很高的，所以应该不是自己发明的某种煞笔加密方法。不过32字节的key，我总以为AES256没什么人用呢。

base64解码以后是376 = 23 * 16 + 8个字节。即使考虑到密文前四个字节更像是某种header或者length，如果是AES的ECB CBC之类的分块模式的话长度也不对，所以要么就是密文里还包含了MAC，或者就是CTR/GCM/EAX模式。如果能肯定是AES的话，就暴力穷举把密文分成几段尝试解密，用熵来判断是否是有意义的明文就行。

楼主说说这密文哪里扒来的，说不定有帮助。

[standin000]

@ccidcce32167 不好意思，\ 是从emacs中粘贴出来的。其实是没有的。
@xurubin 怎么看熵高低啊？密文是抓取网络软件跟服务器交互得来的。

[xurubin]

@standin000 统计每个byte出现的次数，然后用熵的定义来算。不过这里才300多个byte，可能不是很准确。可以改成统计4-bit nibble。

如果是抓取的，你怎么知道密钥是你给的那个？有可能他内部计算用的不是这个呢。

[standin000]

@xurubin 密文和密钥都是发给服务器的，所以应该是配对的。

[xurubin]

@standin000 把密文和密匙一起发给服务器那加密还有什么意义。普通的协议都是服务器和客户端先协商一个密匙，然后通讯的时候用这个加密。

这么猜加密算法的成功率太低了，你有客户端的话直接逆向工程要爽快多了。

[standin000]

@xurubin 密钥是客户端随机生成的啊。

逆向是个办法，估计要消耗很多时间精力

[standin000]

@xurubin 是我理解有误，现在明白了，见附言！

[liuxurong]

好像是Discuz的cookie密文？

[standin000]

@liuxurong 怎么看出来的？

[liuxurong]

@standin000 是么?貌似看过类似的

[standin000]

@liuxurong 不是cookie密文。

[whairg]

@auser key=a50625d3083451d98b2d9f8cf22a3e33159f6c27235da95f 是 AES 的加密请问能解吗？或者找到他们的加密方式