使用其他工具验证AES-256-GCM实现 [英] Verify an AES-256-GCM implementation with another tool

查看:132
本文介绍了使用其他工具验证AES-256-GCM实现的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要验证遵循FIPS-197标准的工具的正确性.因此,我将收到一个三元组,并且我想对这个三元组(密钥,密码,IV)进行解码.

I need to verify the correctness of a tool, that follows the FIPS-197 standard. So I will receive a triple and I want to decode this triple (key, cypher, IV).

有没有一种方法可以简单地做到这一点?是否有任何在线实施可能会有用?

Is there a way to do this simply? Is there any online-implementation, that could be useful?

我刚刚发现,甚至没有两个实现AES-256的页面都具有与输出相同的值.

I just found out, that not even two different pages, that have AES-256 implemented, have the same values as output.

谢谢您的帮助.

我需要验证自己的实现,并且要通过使用已经验证过的工具验证过的测试向量进行验证.

I need to verify my own implementation of this, and I want to do this, by check with test-vectors, that have been verified by an already verified tool.

Edit2:我正在寻找一种验证我的实现的方法.因此,我想到了测试向量或其他已经验证的工具.这是我需要帮助的部分:在哪里可以找到测试向量或此类工具?

I'm looking for a way to verify my implementation. So I thought about test-vectors or another, already validated, tool. This is the part on which I need help: Where can I find test-vectors or such a tool?

我们正在使用"openssl_encrypt"进行评估.

We're using "openssl_encrypt" for evaluation.

$CM = "aes-256-gcm"; //cypher mode
$PT = "";//plain
$CT = "";//cypher
$key = "";
$iv = "";

$cypher = openssl_encrypt($PT, $CM, $key, $options=0, $iv, $tag);

如果要评估标签,则需要执行以下操作:

If we want to evaluate the tag, we need to do:

print(unpack("h*", $tag)[1]);

现在,如果两者相等,我们可以看到与"gcmEncryptExtIV256.rsp"有关的信息.与

Now we can see, if both are equal, regarding to "gcmEncryptExtIV256.rsp" with

[Keylen = 256] [IVlen = 96] [PTlen = 0] [AADlen = 0] [Taglen = 128]

[Keylen = 256] [IVlen = 96] [PTlen = 0] [AADlen = 0] [Taglen = 128]

计数= 0

键= b52c505a37d78eda5dd34f20c22540ea1b58963cf8e5bf8ffa85f9f2492505b4

Key = b52c505a37d78eda5dd34f20c22540ea1b58963cf8e5bf8ffa85f9f2492505b4

IV = 516c33929df5a3284ff463d7

IV = 516c33929df5a3284ff463d7

PT = AAD = CT =

PT = AAD = CT =

标记= bdc1ac884d332457a1d2664f168c76f0

Tag = bdc1ac884d332457a1d2664f168c76f0

我们有:

$CM = "aes-256-gcm"; 
$PT = ""; //plain
$CT = ""; //cypher
$key = "b52c505a37d78eda5dd34f20c22540ea1b58963cf8e5bf8ffa85f9f2492505b4 ";
$iv = "516c33929df5a3284ff463d7 ";

$cypher = openssl_encrypt($PT, $CM, $key, $options=0, $iv, $tag);
print(unpack("h*", $tag)[1]);

这不等于bdc1ac884d332457a1d2664f168c76f0.

This is inequal to bdc1ac884d332457a1d2664f168c76f0.

那我做错了什么?

推荐答案

https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/CAVP-TESTING-BLOCK-CIPHER-MODES#GCMVS is the NIST Cryptographic Algorithm Validation Program (CAVP) page for block cipher modes, including GCM.

在底部包含一个指向测试向量语料库的链接,

At the bottom it contains a link to a corpus of test vectors, https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/mac/gcmtestvectors.zip

例如,在 gcmEncryptExtIV128.rsp 中,您会遇到类似的情况

In, for example gcmEncryptExtIV128.rsp you get cases like

Count = 0
Key = 11754cd72aec309bf52f7687212e8957
IV = 3c819d9a9bed087615030b65
PT = 
AAD = 
CT = 
Tag = 250327c674aaf477aef2675748cf6971

因此,使用键 11754cd72aec309bf52f7687212e8957 (以十六进制指定)和 3c819d9a9bed087615030b65 的IV/nonce(仍为十六进制),空的纯文本和空的关联数据应产生一个空密文和 250327c674aaf477aef2675748cf6971 (是,仍然是十六进制)的auth标记.

So with the key 11754cd72aec309bf52f7687212e8957 (which is specified in hex) and the IV/nonce of 3c819d9a9bed087615030b65 (still hex) the empty plaintext and empty associated data should produce an empty ciphertext and an auth tag of 250327c674aaf477aef2675748cf6971 (yep, still hex).

有很多关于该模式的测试(不同的键,没有明文,没有AAD),然后有很多现在带有AAD",然后仅带有明文",最终出现了类似的情况

There are a whole lot of tests of that mode (different keys, no plaintext, no AAD), then plenty of "now with AAD", then "just with plaintext", and, eventually cases like

Count = 14
Key = f42c74bcf473f6e923119946a89a0079
IV = 14852791065b66ccfa0b2d80
PT = 819abf03a7a6b72892a5ac85604035c2
AAD = 297007ac9419553a292b0fee3a7ac3c9
CT = 48371bd7af4235c4f11c458f1789192a
Tag = 4f44e0aff49a5a20ab2c69c834

让您检查整个套件和kaboodle.不过,一次一个部分"的测试失败可能更易于调试.

Which let you check the whole kit and kaboodle. The "one part at a time" tests failing are probably easier to debug, though.

这篇关于使用其他工具验证AES-256-GCM实现的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆