V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
standin000
V2EX  ›  程序员

请教如何判断加密算法

  •  
  •   standin000 · 2014-05-05 10:45:13 +08:00 · 16083 次点击
    这是一个创建于 3857 天前的主题,其中的信息可能已经有所发展或是发生改变。
    它的密钥是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
        1
    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
        2
    duzhe0  
       2014-05-05 13:06:14 +08:00
    1.你给的密钥应该是256位的2进制数据的hex值, 不是64个字符
    2.密文应该是base64的
    dong3580
        3
    dong3580  
       2014-05-05 13:13:36 +08:00
    你这个有点像是RSA加密的嘛,不过位数怎怎么长,结尾一个==,无解。
    eOUP+q78QFyELsBHs6jpvr9EtDO+Dzdev2qBiElSzmAPImqSpSs5PQfqUpYMFMbNXiGH09ppJM/1+qNH0AXd6RCE5FWr/dBXyoDhAbkQyFXn3kLPGkFbfr5yM+XgryrAmS0b7aGmCJwxUNBhmIzFEZNDyaVwb0KTaiMBQNFcLk4=
    standin000
        4
    standin000  
    OP
       2014-05-05 13:34:31 +08:00
    @duzhe0 那密钥是32个字节,但base64加密是不需要密钥的,这个怎么解释?
    standin000
        5
    standin000  
    OP
       2014-05-05 13:34:47 +08:00
    @auser
    @dong3580 都是觉得密钥太长了吗?
    duzhe0
        6
    duzhe0  
       2014-05-05 13:45:01 +08:00
    @standin000 多次加密,最后一次是base64
    oott123
        7
    oott123  
       2014-05-05 14:19:43 +08:00 via Android   ❤️ 1
    base64 是编码,不是加密。
    由于你通过各种算法加密出来的可能是一堆二进制数据,不便于传输或者怎样,所以加密完之后做个 base64 。

    回到算法问题,我认为没有可以判断的方法。
    xierch
        8
    xierch  
       2014-05-05 17:02:23 +08:00
    考虑到原文应当是有意义的数据而非随机数据
    应该还是有可能推测出加密算法的(?)
    auser
        9
    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
        10
    raptium  
       2014-05-05 20:18:34 +08:00 via Android
    密文看起来是 base64 编码的
    解码后看到开头 4 个 byte 像是“信息长度”
    其他就不知道了
    standin000
        11
    standin000  
    OP
       2014-05-05 21:03:00 +08:00
    @auser 我有点不理解,已经知道密钥和密文,又知道加密算法的话,当然可以解密和再加密了。

    @raptium 你是用base64解码后的前4个byte吗?有点不像长度了。
    raptium
        12
    raptium  
       2014-05-05 21:04:40 +08:00 via Android
    @standin000 挺像长度的啊 才差了十几个 byte
    auser
        13
    auser  
       2014-05-05 22:40:37 +08:00 via iPad
    @standin000 AES是块加密,自行搜索块加密。每次加密输入是128位,对应128位输出。假如你要加密00001111(二进制串),你不填充到128位怎么加密?我之前实现用的是pkcs7. 其它还有很多填充标准。题外话,MD5算法也要用填充,用的是位填充,貌似必须补齐512位,记不清了。

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

    里边细节问题很多。想知道的话自己搜吧。
    EOF
    lsylsy2
        14
    lsylsy2  
       2014-05-05 22:47:26 +08:00
    其实我倒觉得这个问题是可解的,如果这是完整的密文(没有CBC之类)……
    加密算法构建的目的基本都是“知道算法,知道密文,不知道密钥的情况下无法获取明文”,而不是知道密文密钥不知道算法。
    考虑写个程序,试验下各种算法吧,费点事而且不一定有结果就是了
    ccidcce32167
        15
    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
        16
    zoho  
       2014-05-06 16:25:06 +08:00 via iPad
    @ccidcce32167 不是有三个 \ 么?应该拆成四段啊。
    xurubin
        17
    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
        18
    standin000  
    OP
       2014-05-06 19:59:45 +08:00
    @ccidcce32167 不好意思,\ 是从emacs中粘贴出来的。其实是没有的。
    @xurubin 怎么看熵高低啊?密文是抓取网络软件跟服务器交互得来的。
    xurubin
        19
    xurubin  
       2014-05-06 21:23:44 +08:00
    @standin000 统计每个byte出现的次数,然后用熵的定义来算。不过这里才300多个byte,可能不是很准确。可以改成统计4-bit nibble。

    如果是抓取的,你怎么知道密钥是你给的那个?有可能他内部计算用的不是这个呢。
    standin000
        20
    standin000  
    OP
       2014-05-06 23:38:33 +08:00
    @xurubin 密文和密钥都是发给服务器的,所以应该是配对的。
    xurubin
        21
    xurubin  
       2014-05-06 23:44:56 +08:00
    @standin000 把密文和密匙一起发给服务器那加密还有什么意义。普通的协议都是服务器和客户端先协商一个密匙,然后通讯的时候用这个加密。

    这么猜加密算法的成功率太低了,你有客户端的话直接逆向工程要爽快多了。
    standin000
        22
    standin000  
    OP
       2014-05-07 11:02:03 +08:00
    @xurubin 密钥是客户端随机生成的啊。

    逆向是个办法,估计要消耗很多时间精力
    standin000
        23
    standin000  
    OP
       2014-05-10 22:06:08 +08:00
    @xurubin 是我理解有误,现在明白了,见附言!
    liuxurong
        24
    liuxurong  
       2014-05-10 22:46:07 +08:00
    好像是Discuz的cookie密文?
    standin000
        25
    standin000  
    OP
       2014-05-12 14:55:37 +08:00
    @liuxurong 怎么看出来的?
    liuxurong
        26
    liuxurong  
       2014-05-15 02:43:06 +08:00
    @standin000 是么?貌似看过类似的
    standin000
        27
    standin000  
    OP
       2014-07-02 16:07:31 +08:00
    @liuxurong 不是cookie密文。
    whairg
        28
    whairg  
       2019-09-16 11:40:06 +08:00
    @auser key=a50625d3083451d98b2d9f8cf22a3e33159f6c27235da95f 是 AES 的加密请问能解吗?或者找到他们的加密方式
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5547 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 08:32 · PVG 16:32 · LAX 00:32 · JFK 03:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.