ANSI 9.63 KDF

[harrywangca]

I am not sure if this is a bug on demo server yet.

I am verifying ANSI 9.63 kdf vectors with the demo server. Attached is a vector file I downloaded with libacvp. You can see from time to time, ‘z’ value is 1 byte shorter than fieldSize indicated. See tcId 74, 102, 287, 1899 in the file. Likely libacvp cut the ending zero when downloading the vectors.

I’ve tried two ways to generate key data, but both failed to verify. One is padding zero to z, the other is minute 1 to fieldSize, Hope someone can tell me what is the right way to deal with this, or if this is a bug on the server.

Some details below.

Harry

environment
Demo

testSessionId
101419

vsId
295594

Algorithm registration
rv = acvp_cap_kdf135_x963_enable(ctx, &app_kdf135_x963_handler);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_set_prereq(ctx, ACVP_KDF135_X963, ACVP_PREREQ_SHA, value);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_HASH_ALG, ACVP_SHA224);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_HASH_ALG, ACVP_SHA256);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_HASH_ALG, ACVP_SHA384);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_HASH_ALG, ACVP_SHA512);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_KEY_DATA_LEN, 128);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_KEY_DATA_LEN, 2048);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_FIELD_SIZE, 224);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_FIELD_SIZE, 571);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_SHARED_INFO_LEN, 0);
CHECK_ENABLE_CAP_RV(rv);
rv = acvp_cap_kdf135_x963_set_parm(ctx, ACVP_KDF_X963_SHARED_INFO_LEN, 512);
CHECK_ENABLE_CAP_RV(rv);

[celic]

Hi, please do not upload jwt values anywhere. I'll take a look and double check from our end.

[celic]

It looks like there are cases where a leading 00 byte is being dropped from the z value. This is a bug, we'll fix it soon. The 00 byte should be the leading byte, on the left. For some insight as to why this is happening, we store the z values as integers (BigInteger in C#) so when we end up with a random integer value that does not have any bits in the first byte, the internal structure to BigInteger doesn't store it. We end up padding these later, and sometimes they are missed as there's only a 1/256 chance of an empty byte leading the value.

[harrywangca]

FYI:

I just tried a --sample test. It still failed even when I put a leading zero for z. (see tmp)

My printout:
***ACVP [INFO][acvp_kdf135_x963_kat_handler:277]--> Found new KDF135 X963 test vector...
***ACVP [INFO][acvp_kdf135_x963_kat_handler:302]--> Test case: 5
***ACVP [INFO][acvp_kdf135_x963_kat_handler:303]--> tcId: 46
app_kdf.c(97) tc_id=46, kdfAlg=3 field_size=28 shared_info_len=64 key_data_len=16
z(28)=
0x51, 0x9e, 0x70, 0xe4, 0x65, 0xfc, 0x7e, 0x49,
0x3b, 0x5c, 0xe3, 0x76, 0x27, 0x0c, 0x6e, 0x3b,
0x05, 0x91, 0x6f, 0xaa, 0xe7, 0x94, 0x49, 0x5c,
0x9e, 0xdc, 0x36, 0x00,
shared_info(64)=
0x48, 0x7f, 0x6b, 0x03, 0xa9, 0x85, 0x92, 0x54,
0x0a, 0xc0, 0xe6, 0x22, 0xe8, 0xef, 0x7e, 0xf0,
0x06, 0x48, 0x36, 0xd6, 0x12, 0x67, 0x53, 0x81,
0xfc, 0x35, 0x45, 0xfd, 0xef, 0x1a, 0x42, 0xaa,
0xec, 0xb9, 0x77, 0x39, 0x81, 0x3c, 0x25, 0xc6,
0xde, 0x66, 0xc3, 0x91, 0xb7, 0x4e, 0xfb, 0x75,
0x7e, 0x8e, 0x43, 0xf2, 0x26, 0x0c, 0x64, 0xbf,
0xb9, 0xec, 0x3f, 0xcf, 0x4b, 0x71, 0xba, 0xcd,

tmp(28)=
0x00, 0x51, 0x9e, 0x70, 0xe4, 0x65, 0xfc, 0x7e,
0x49, 0x3b, 0x5c, 0xe3, 0x76, 0x27, 0x0c, 0x6e,
0x3b, 0x05, 0x91, 0x6f, 0xaa, 0xe7, 0x94, 0x49,
0x5c, 0x9e, 0xdc, 0x36,
key_data(16)=
0x26, 0xcb, 0x2c, 0x45, 0x97, 0x9c, 0xfe, 0xf9,
0x26, 0x50, 0xda, 0xbd, 0x84, 0x89, 0xdc, 0x3b,

Expected result:
"tcId": 46,
"keyData": "B6913266E123D9F7148A3C020E30186C"

[celic]

I double checked the test case there, and it seems like the Z just coincidentally has the last byte as 00. All bytes are present in the JSON so that test case needs no special treatment.

For Z values that appear one byte too short, the leading byte is supposed to be 00.

[celic]

The fix was deployed last night. Please check when you can.

[harrywangca]

My test passed with updated demo server. Thanks.