IKEv1 and IKEv2 when dhLength smaller than length of gir message

[gx2955]

For IKEv1 and IKEv2, it is possible to get a

Test Group:
dhLength=4348

Test case:
gir=ED6DAAE... (Total contains 1088 characters in hex, so 544 bytes, so 4352 bits)

Where dhLength(in bits) < gir length(in bits). In CAVP document such like this it talks about when dhLength > gir length, and provided request vectors are all dhLength > gir length. In cryptography, it seems like dhLength(in bits) < gir length(in bits) is an invalid input. PLUS, the "gir" starts with "E", which is not a padding with 0.

Same story happened in IKEv1. May I know are these valid input? If so, how to handle when dhLength(in bits) < gir length(in bits) such case?

[livebe01]

Hi @NorthHill-16, I was reviewing some of our older open tickets and found this one. Is this still an open question/something you would like us to look into?

[gx2955]

Hi, @livebe01 , yes, this issue actually not solved yet. Currently I force the dhLength to be multiple of 8. This solution has no problem so far.

Based on old CAVP document (https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/components/askdfvs.pdf) page 9, when dhLength not multiple of 8, padding is needed. I apply this method, then compute the result and sent to ACVP, ACVP says result wrong for these tcid.

Question in short:
How ACVP server pad the gir message when provided dhLength is shorter than provided gir length?

[celic]

Padding is placed on the LSB (right) side of the hex string. So a one bit message is "80". It appears like you would need to truncate the hex from gir down to match the dhLength value by truncating bits from the right-side of the hex.

[gx2955]

Hi, @celic, sorry for late reply. I am truncating from right side, since it does not work then I try to truncate from left side. The root cause of this question is about how to "truncate" at right side. So far I tried 3 methods and none of them worked yet, I slightly guess server mis-behave or actually not support "increment: 1" in register file or I mis-understand.

Take following case as example, IKEv1, and use HMAC-SHA256 as PRF function. A real sample data from server,
"nInitLength": 396
"nInit":"0C0454BE6D5EE9F10BF4C7CC532C6DAB679AF83A8ACE96060B950048ACE931D120AD6EBEC015647058A0A9CFF540264562E0"

Method #1: No action
Since the right side is 0(397-400 bits), and we need to get a size of multiple of 8, so we treat it as 400 bits, in other word, treat it as 400 bits and do nothing during message merge and PRF.

Method #2: Use truncated bits do message merge and add the padding before PRF
We treat nInit as 396 bits when doing "message merge", and we pad the 0 at end of "merged message" to get a size of multiple of 8, then input this message to HMAC. Take an example, for PSK method(RFC 2409 page 9),
SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

Ni is 396 bits and Nr is 1024 bits, we merge together and get 1420 bits, then pad 4 right-most 0 to get 1424 bits. Input this message to HMAC.

Method #3: No padding at all
Because above method not work, I doubt "truncate" here means really "cut" and do bit-oriented hash(which is not supported in OpenSSL). Continue example in method 2, Ni and Nr merge together get 1420 bits, then I apply my self-implemented mini crypto engine and do a 1420 bits HMAC-SHA256, and server reports failed still.

Following are detailed computation. Refers to tsId 1328915 tgId 1 tcId 1. Server does not return the sample answer(get 404 error) even I specify sample flag.

CONFIG
"hashAlg": "SHA2-256",
"authenticationMethod": "psk",
"dhLength": 224,
"nInitLength": 396,
"nRespLength": 1024,
"preSharedKeyLength": 2048,

OPERANDS
"ckyInit": "7C44F863BFFF7761",
"ckyResp": "27A191DC6309F0F8",
"nInit": "0C0454BE6D5EE9F10BF4C7CC532C6DAB679AF83A8ACE96060B950048ACE931D120AD6EBEC015647058A0A9CFF540264562E0",
"nResp": "B6D8D6063AB3FB9CC8AC5D938D67A531124347EB56396532B8348F8329AA0785387B10CB36AE4E6F8DE715C83BA82D0BC7220DC784AFDDC6A40CB488228983DE75993CBA736C541F0ACC9B33000A3E6CBDB20CAD887D1E743584388ACD593B291A15D27A15EABED4D09644A324124BDC9782E25EB29EF3481351A4314125B54F",
"gxy": "A394EB6039AE844874F4828C5BB1FADC888DE15A27A4EEA826049C0A",
"preSharedKey": "3317CDE61D1414BB040B89919E85A2A5F018A4F2B6DA5F12ED4146E4E61CC7C0F57384B422250967F7F682669815DC6287773D2D8223C3B7CCF00B277B0BB2877121A77AE82A1D2E4526157A922C03F868C1F098A438E19CEE6CDE40534F8D0D7114929B0E4523780FE16664C0B224AB305E760919239C04BDB5C00CA22C10AC8AD62CB6D83457DECB09BB403D9F52AE78816C63FB17E39ECB6ACF6624EE82CA22A30313619D2D9DC27121FDC1676F8C1CE4FB24F7324F8DE98D5305D11A50EC077CA8AC2B6E9373A664964BA4CD2C1F6FA18074DB8947CB502E81F410D30159BDC5CAED86DF2D9C59D6AE3EFEA0BB6B8264D8D3730DB1D26A2F8B590BEC4954"

Method 1: Fail
"sKeyId": "6AE7528C5196CEBE4665850A40143276E9FFFEEA809B1A33F2D11C863EE54D0D",
"sKeyIdD": "2D378C5589A9A44CFFC4F64C40F40D7DA8F60BF2BF23D802941ED25B62853529",
"sKeyIdA": "3CEDAC96526F5D7757D5B85EEE72BF67939B71CFDA7E9D8CB64546A2ACD04A0A",
"sKeyIdE": "2BFCE22A2C5F064BEA428C4722A48CF59D6E6C77560D1A7D6F75498E66F9969D",

Method 2: Fail
SKEYID : 6571425E257954FCB5868A843F89945933BD07BB95358F80053D229E639399C0
SKEYID_d: C0C53D133D3EF90F12E56723E63C6FE37E49A628D36A1F7779D206065B2BAC07
SKEYID_a: 1E26F7878150552270E14236D9B3EF4D9BB163C7C431864E732BA55D831EB048
SKEYID_e: FB0D2324752D7E9DB2D06F3F10BF188C03791CCD3E2775CC547C098597A72473

Method 3: Fail
SKEYID : B92EDBB4B6F15DB07FED293D06A5042759093E6F3E39BE295EDC22CCEEF0EF77
SKEYID_d: 53FFD84D6D05BE3075587B00186FDBD45920EC31136640D5EF28CF9E6E59A00C
SKEYID_a: A90196CCCBFFF29B2C23AA91E843545C504CC344939E8106AE09104E942CFE97
SKEYID_e: 750FDC3615BFC20F4D6CB5969A928FA6BA8BE16471A090093E2A9956E27CAB5B

Additional Observation:
When "preSharedKeyLength" is not multiple of 8, apply method #1 and it will pass. I think this makes sense because FIPS 198 defines Key size in bytes. If so, then why server provide something like "preSharedKeyLength": 1381 ? It has no difference with 1384 bits.

[gx2955]

Also, this is not an important question since I can force incremental to 8 in register file. These parameter seems introduced in ACVP, so far I have not seen similar case in CAVP test vector.