content of hybrid public key

[petrovr]

Function EVP_PKEY_get_octet_string_param with arguments OSSL_PKEY_PARAM_PUB_KEY returns some data.
For key X25519MLKEM768 I expect to see output that contains concatenation of respective public parts.

Current output is with length 1220=4(?)+1184+32.

Why output contain (starts) with length of x25519 key?

[baentsch]

The reason for this is that some classic algs may have a length less than the maximum length and the logic in oqs-provider is generic in that sense (handling also that case, thus encoding the actual length in 4 bytes). If you could point to a specific specification that mandates this to be different (and how) please provide a pointer so we can properly treat this as a bug and solicit PRs to change this behaviour.

[petrovr]

Now I have draft implementation of mlkem768x25519-sha256, see
https://datatracker.ietf.org/doc/html/draft-kampanakis-curdle-ssh-pq-ke-04 .
It uses EVP and PKEY API with activated oqs-provider.

For protocol dump shows that OSSL_PKEY_PARAM_PUB_KEY for X25519MLKEM768 return data that starts with 32 (four bytes) + 1184 bytes + 32 bytes.

---

Project openssh is out of scope as it uses archaic OpenSSL API.

Soon I will publish PKIX-SSH draft implementation as new branch. Implementation pass interoperable tests with asyncssh (uses dynamically loaded oqs library).

[baentsch]

Soon I will publish PKIX-SSH draft implementation as new branch.

Thanks for letting us know (also thanks for the spec pointer) @petrovr ! It would be helpful if you could post a pointer here as and when (and where!) you have published this when you're done -- and particularly if you think some code changes in oqsprovider are required: Thanks in advance.

[baentsch]

Issues doesn't seem to require attention, so closing. Feel free to re-open as needed.

[petrovr]

More than one month a have prototype of "PQ/T Hybrid Key Exchange in SSH" (draft-kampanakis-curdle-ssh-pq-ke-NN) that uses OpenSSL PKEY with key generation, encapsulation, and decapsulation. Prototype "dumps" a lot of "internal information".

Defect is inspired from prototype.

Let review just published hybrid_demo commits. "HYBRID-DEMO: public part hack" in required.

So which standard defines that public key must start with length of classical key?

Note this is first issue about "content". It seems to me this is common case.

---

[petrovr]

@baentsch I think that issue should be reopened.

[baentsch]

@baentsch I think that issue should be reopened.

No problem doing that.

I'm still a bit confused, though: How can the format of the hybrid public key be incorrect, given that this code seems to be able to successfully complete hybrid TLS1.3 KEM handshakes (where the public key is exchanged, right?) as per

oqs-provider/scripts/oqsprovider-externalinterop.sh

Line 52 in 98ec7fc

echo -e "GET / HTTP/1.1\r\nHost: www.google.com\r\nConnection: close\r\n\r\n" | "${OPENSSL_APP}" s_client ${USE_PROXY} -connect google.com:443 -groups X25519MLKEM768 -servername google.com >/dev/null 2>/dev/null

[petrovr]

Hi @baentsch ,

I do not know SSL/TLS .
When I run s_client utility with group X25519MLKEM768 in trace mode I note following:

...
Sent TLS Record
...
        extension_type=key_share(51), length=1222
            NamedGroup: UNKNOWN (4588)
            key_exchange:  (len=1216): B4F64D913435 ... ... ...
...
Received TLS Record
        extension_type=key_share(51), length=1124
            NamedGroup: UNKNOWN (4588)
            key_exchange:  (len=1120): B55CDCE59A ... ... ...
...

If I read properly exchanged data 1216(=1184+32) is public part.
Hexidecimal sequence starts B4F6. This does not lock like length of classical key.

In test/demo code extract of public is with length 1220 and sequence like 00 00 00 20 8C 68 60 D2 76.

No idea what is difference in code path between s_client and as test/demo code.
Demo uses "EVP_PKEY_get_octet_string_param(..., OSSL_PKEY_PARAM_PUB_KEY, ...".

[baentsch]

Well in that case, the logic seems to be correct for TLS encoded public keys (leaving away the classic key length). Begs the question what happens (edit/add: is expected) in SSH case (for which no specific code has ever been written or tests devised). The latter point actually now is my proposal to get to the bottom of this:

Would it be possible for you to provide a (SSH-based) test case that currently fails and that should require a code update to pass, @petrovr ? This might serve as a blueprint (edit/add: suggestion what needs changing to support both use cases).

[baentsch]

Demo uses "EVP_PKEY_get_octet_string_param(..., OSSL_PKEY_PARAM_PUB_KEY, ...".

That then is the explanation: The encoded format omits the length field while the raw form above contains it. Question then is: What parameter does SSH use? And: Would there be any client code complaining if the contents of OSSL_PKEY_PARAM_PUB_KEY were changing?

[petrovr]

Hi Michael, На 2.12.24 г. в 9:22 ч., Michael Baentsch написа:

Well in that case, the logic seems to be correct for TLS (leaving away the classic key length). Begs the question what happens in SSH case (for which no specific code has ever been written or tests devised). The latter point actually now is my proposal to get to the bottom of this: Would it be possible for you to provide a (SSH-based) test case that currently fails and that should require a code update to pass, @petrovr ?

Short answer - no. [This](https://github.com/open-quantum-safe/oqs-provider/blob/main/scripts/oqsprovider-externalinterop.sh) might serve as a blueprint.

Not with this model. Code has some tests designed to test interoperability. It seem to me cost to setup public test environment is excessively high. Roumen

[petrovr]

На 2.12.24 г. в 12:52 ч., Michael Baentsch написа:

> Demo uses "EVP_PKEY_get_octet_string_param(..., OSSL_PKEY_PARAM_PUB_KEY, ...". That then is the explanation: The encoded format omits the length field while the raw form above contains it. Question then is: What parameter does SSH use?

I'm lost. Function EVP_PKEY_get_octet_string_param uses well defined arguments. Instead OSSL_PKEY_PARAM_PUB_KEY I could use another but which one.

And: Would there be any client code complaining if the contents of OSSL_PKEY_PARAM_PUB_KEY were changing?

No idea. Change of value returned by OSSL_PKEY_PARAM_PUB_KEY may require changes in EVP_PKEY_new_raw_public_key_ex . Roumen P.S. It is quite interesting to me how TLS get "correct" value.

[baentsch]

P.S. It is quite interesting to me how TLS get "correct" value.

Also for me: A "history lesson" with an implementation following different "hybrid" proposals over time -- very clearly making the case again for redoing this properly as per #375.