我用对称加密创建了一个加密文件。
gpg -c 50GBfile
Run Code Online (Sandbox Code Playgroud)
现在我想删除原来的。在我删除原始文件之前,我想验证加密文件的完整性。(类似于 ZIP 文件使用 CRC 的方式)。gpg 是否提供验证对称加密文件内容的方法?
如果您使用 加密文件gpg -c
,则在不知道密码的情况下无法验证文件包含的内容。这是对称加密的核心属性。由于无论如何您都需要提供密码,因此请进行真正的测试:解压缩文件并将其与原始文件进行比较。在 Linux 或其他 UNIX 变体上:
gpg -d <50GBfile.gpg | cmp - 50GBfile\n
Run Code Online (Sandbox Code Playgroud)\n\n如果您想要额外的完整性保证,可以通过-s
在加密文件时添加该选项,使用私钥对文件进行签名。
gpg -c -s 50GBfile\n
Run Code Online (Sandbox Code Playgroud)\n\n然后您可以使用 验证签名gpg --verify 50GBfile.gpg
。请注意,这只能保证该文件是您已签名的文件之一,并不能保护您免受签署错误文件的错误的影响。
如果您使用非对称加密(使用收件人的公钥 \xe2\x80\x94\xc2\xa0 您自己的公钥),则验证文件是否具有所需的内容将需要收件人的私钥。对于多个收件人,任何收件人的私钥都可以。通常,您会将自己的密钥作为所有加密消息的接收者,与 GPG 配置文件一起放置encrypt-to
或hidden-encrypt-to
放置在 GPG 配置文件中。
gnupg 中唯一的“验证”操作是签名验证,它基本上使用公钥(=sign)对加密文件的散列进行加密。
在我看来,这意味着如果在加密文件时输出位被损坏,将针对损坏的文件计算散列。由于您签署了一个已损坏的文件,因此您永远不会通过验证该文件的签名来发现这一点。
似乎要积极验证加密文件是否损坏的唯一方法是经历冗长的解密生成文件并将其散列与原始文件进行比较的过程。
这就是 Sepero 上面提供的,但不是“您可以验证……”,而应该是“验证……的唯一方法”
更新 - 将要点带回家:
几分钟前我就是这样做的:将一个 9.8GB 的备份文件拆分为 5 个 rar 片段,每个片段都由 gnupg 对称加密。在删除 rar 片段之前,我验证了加密片段的完整性,如上所述:5 个中有 1 个没有通过哈希测试。我再次解密了那个片段,现在解密片段的哈希确实与原始 rar 片段匹配。
我将坏的解密 rar 部分与好的解密 rar 部分进行了比较,这些 2GB 文件的唯一区别是一个字节:C8 与 48 - 这是由 1 位翻转引起的(即 11001000 与 01001000)。
这个故事的寓意是,如果在一个好的 WIN7 系统和一个好的 HDD 上,gnupg 可以在解密方面稍微改变一下,它也可以在加密方面做到这一点。我永远不会再跳过这个完整性验证步骤。
小智 2
您可以通过提取 md5sum 并将其与原始值进行比较来验证它。
$ gpg -d 50GBfile | md5sum
gpg: AES256 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
1df1aaffb20c5255e282d6f584489993 -
$ md5sum 50GBfile
1df1aaffb20c5255e282d6f584489993 50GBfile
Run Code Online (Sandbox Code Playgroud)
归档时间: |
|
查看次数: |
5054 次 |
最近记录: |