请教如何判断加密算法

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3854 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

请教各位有什么线索吗？

第 1 条附言 · 2014-05-10 22:03:55 +08:00

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

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

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

加密

请教

加密算法

28 条回复 • 2019-09-16 11:40:06 +08:00

auser

2014-05-05 12:15:17 +08:00

实现过DES和AES.

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

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

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

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

综上，无解。

duzhe0

2014-05-05 13:06:14 +08:00

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

dong3580

2014-05-05 13:13:36 +08:00

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

standin000

2014-05-05 13:34:31 +08:00

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

standin000

2014-05-05 13:34:47 +08:00

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

duzhe0

2014-05-05 13:45:01 +08:00

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

oott123

2014-05-05 14:19:43 +08:00 via Android

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

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

xierch

2014-05-05 17:02:23 +08:00

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

auser

2014-05-05 20:00:55 +08:00

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

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

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

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

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

raptium

2014-05-05 20:18:34 +08:00 via Android

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

standin000

2014-05-05 21:03:00 +08:00

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

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

raptium

2014-05-05 21:04:40 +08:00 via Android

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

auser

2014-05-05 22:40:37 +08:00 via iPad

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

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

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

lsylsy2

2014-05-05 22:47:26 +08:00

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

ccidcce32167

2014-05-06 11:46:12 +08:00

说下我的进展：我刚才查了一下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

2014-05-06 16:25:06 +08:00 via iPad

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

xurubin

2014-05-06 19:50:23 +08:00

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

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

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

standin000

2014-05-06 19:59:45 +08:00

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

xurubin

2014-05-06 21:23:44 +08:00

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

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

standin000

2014-05-06 23:38:33 +08:00

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

xurubin

2014-05-06 23:44:56 +08:00

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

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

standin000

2014-05-07 11:02:03 +08:00

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

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

standin000

2014-05-10 22:06:08 +08:00

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

liuxurong

2014-05-10 22:46:07 +08:00

好像是Discuz的cookie密文？

standin000

2014-05-12 14:55:37 +08:00

@liuxurong 怎么看出来的？

liuxurong

2014-05-15 02:43:06 +08:00

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

standin000

2014-07-02 16:07:31 +08:00

@liuxurong 不是cookie密文。

whairg

2019-09-16 11:40:06 +08:00

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