Re: [CFRG] HPKE test vector request - deterministic key gen that requires iteration

[Stephen Farrell <[e-mail]>]

Hiya,

Thanks Ilari, that's great to get.

On 16/07/2022 11:42, Ilari Liusvaara wrote:
> On Sat, Jul 16, 2022 at 12:44:09AM +0100, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> HPKE includes deterministic key generation based on an
>> initial key material (IKM) value. There's an iterative
>> DeriveKeyaPair scheme for NIST curves. [1]
>>
>> I recently added some tests using the test vectors from
>> RFC9180 but the deterministic key gen ones I found only
>> seem to exercise the code that doesn't need to iterate,
>> i.e., they succeed immediately with the counter at zero.
>>
>> Does anyone have a test vector with an IKM value that
>> requires iteration?
> 
> No idea if this is correct, 

Well, it works the same here! Mind you, I did have to fix
a really silly bug that was obvious once I ran the code,
which was my whole reason for asking:-)

> but with my implementation of HPKE, I get:
> 
> kemid:   P256
> ikm:     000000000000000000000000000000000000000000000000000000030138b5ec

I'm guessing from the above value you just searched for that.
If so, thanks again for saving me the work of doing that too!

> dkp_rpk: 55f64db8e620e8373551ae9e45e6802a985b027cd043d73dd0fec6de9e094367
> bytes0:  ffffffff213dbec7d0a4e48002a3abc2ae736d3de1e19755c65ee86fba8d7307
> bytes1:  02010edfe618aeb55ba93bae1521c4a1e83c3db89cd976cc459a822bd1034bb4
> 
> As note, the first candidate scalar it computes is:
> 
> 115792089213856954898469474048607274691333539784456088236989463005489886229255
> 
> Which exceeds the P-256 order:
> 
> 115792089210356248762697446949407573529996955224135760342422259061068512044369
> 
> (115792089213... > 115792089210...)
> 
> The second candidate is:
> 
>     906495204980253860296648081872579350626967427403362137130682426765428870068
> 

All those are calculated the same by my code.

And the encoded public key I get as a result is:

047d 0c87 ffd5 d145 54a7 51df a399 26a9
e30e 7c3c 6562 4f4b 5fb3 ad7a a4da c24a
d8f5 bed0 e86e b884 1ce4 892e 0fc3 87bb
dbfe 160d 589c 892d d4b1 464a c351 c56f
b6


> Which is in range so it is the result.
> 
> Finding P-256 vector causing two iterations would require massive
> effort. And finding P-384 and P-521 vectors causing iteration is just
> far beyond what can be done. And even single iterations with P-256 are
> 1 in ~4 billion events.

Yeah, not sure how to handle that kind of thing if one
has to deal with such unlikely events. But at least with
one p256 test vector the code's been tested so I guess
we only risk interop with p384 and p521 rather than there
being other bugs in untested code.

Cheers,
S.

> 
> 
> 
> 
> 
> -Ilari
> 
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg