randombit / botan

Cryptography Toolkit
https://botan.randombit.net
BSD 2-Clause "Simplified" License
2.6k stars 570 forks source link

Naming/Behviour of Public_Key.key_length() method #722

Closed mgierlings closed 8 years ago

mgierlings commented 8 years ago

9c72dab introduces the key_length() method for Botan::Public_Key. The documentation explains the purpose of this method as

* Return an integer value best approximating the length of the
* primary security parameter...

While for many algorithms the key length and the length of the primary security parameter are similar, in case of XMSS the actual key lengths, which at the moment are returned by XMSS_Public_Key.size() and XMSS_Private_Key.size(), are different.

I.e. for XMSS_SHA2-512_W16_H10 the key strength is 512 Bit, which is also what is returned when key_length() is being called. However the actual length of the XMSS public key for this parameter set is 1056 Bit, the XMSS private key length is even 2144 Bit. These values are actually returned when size() is called on the XMSS keys. So neither of these keys has the length of the primary security parameter, which we assume to be n at the moment. I'm wondering is 512Bit really what is expected to be returned here, especially since estimated_strength() seems to be doing the exact same thing.

randombit commented 8 years ago

I think the idea of key_length is "the integer value best approximating what a policy check on key strength would be interested in." So for XMSS the values 256 and 512 seems appropriate, because a policy mentioning XMSS strength would probably say something like "XMSS must be used with a 512-bit hash function." rather than "must have a 1056 bit public key".

Re estimated_strength, that key_length == estimated_strength in XMSS is just an artifact of XMSS being a hash based scheme and that estimated_strength returns pre-quantum security level. One could imagine a point when all estimated_strength settings are adjusted to post-quantum values at which point XMSS estimated_strength returns 128 or 256 instead, but key_length value would be unchanged.

The size API in XMSS is again a different value altogether (though a useful one - it would be worth expanding this all other pubkey types eventually, since in all cases the encoded size can be known in advance and being able to inquire the encoded length without encoding can be convenient). But, I think size [raw encoded key size], key_length [length of key for policy check purposes] and estimated_strength [best estimate of key workfactor] are all meaningful and (typically) distinct values.

mgierlings commented 8 years ago

Thanks for elaborating this, just wanted to make sure we're doing the right thing here. I'll close this then.