当我们拥有原始消息和加密消息时,它可能还是可以找到加密方法的工具?
示例:加密消息:ZHVoYW1lbA:原始消息:duhamel
示例2:加密消息:ZmV5:原始消息:fey
当我们拥有原始消息和加密消息时,它可能还是可以找到加密方法的工具?
示例:加密消息:ZHVoYW1lbA:原始消息:duhamel
示例2:加密消息:ZmV5:原始消息:fey
不。
您所能做的就是使用消息的长度来确定它是块密码还是流密码(如果是块密码,它们将是某个固定大小的倍数)。即使这样也需要小心,因为您需要猜测是否使用了 IV 和 HMAC 或类似的东西(例如,在 CTR 模式下,(所谓的)IV 是半个块)。
如果您的示例是真实的,那么这不是分组密码,因为加密的消息太短了。而且我真的不明白编码是什么——通常加密的消息是二进制的,而不是字符,所以写成十六进制字符串或类似的。但是您的示例似乎是字符串。
因此,您的示例要么是编造的,要么是不寻常的——更可能是“自制”代码,而不是软件库中使用的标准算法。
上面说的是加密。然而,有时人们实际询问的是编码。这就是(可能是加密的,但可能不是)消息中的字节如何转换为通过 Internet 或其他方式显示或发送的内容。这可能是十六进制,或以 64 为基数,或者像 PEM 这样更复杂的东西。通常你可以猜到这一点,因为不同的编码往往看起来不同。例如,Base 64 通常以“=”结尾。有时,这可以为您提供有关所使用加密的线索。例如,PEM 具有独特的标头行,这使其易于识别,并且 OpenSSL 中 PEM 的默认密码是三重 DES,因此如果文件是 PEM 编码的,则很可能它是三重 DES 加密的。
因此,鉴于此,我应该在我的原始答案中包含编码有时也可以帮助猜测密码类型的注释。在您的示例中,两个加密字符串都以“Z”开头很奇怪。但我不知道这样做的编码。
[另请参阅https://stackoverflow.com/a/20217208/181772上的相关评论]