[0rlych1kk4]

This PR adds the QR-UOV integration layer required for inclusion in liboqs.

It includes:

• liboqs-backed SHAKE, AES and memory cleansing support behind QRUOV_PRIM_OQS
• namespacing for ref, opt, and avx2 implementations
• an OQS_randombytes adapter
• detached signature/verification wrappers expected by liboqs
• META files for all 30 Round 3 parameter/PRG combinations
• AVX2 platform metadata

Validation performed:

• ref AES and SHAKE smoke tests passed
• opt detached sign/verify smoke test passed
• AVX2 cross-compilation succeeded for x86_64
• namespace audit across all 15 parameter sets reported 0 un-namespaced globals
• all 30 META files parse successfully

The primitive backend changes are based on the liboqs adapter work shared by @paschal533 .

The macOS-specific src/util.h workaround is intentionally not included in this PR.

[0rlych1kk4]

@qruov @baentsch The corresponding liboqs integration PR is now under review, and one remaining review item is to replace the temporary fork pin with the official qruov/round3 repository.
This PR contains the integration metadata and adapter support currently used by liboqs, including the latest namespace portability fixes.
Once this is merged, I can update liboqs to pin the official upstream commit and resolve that review item.
Could you please review this PR when convenient?

[baentsch]

fwiw, LGTM; see 2 small separate comments and one basic question: Did all these .yml files get manually created? If so, would it be worth while considering a script to re-do them as/when the need arises to limit the possibility for the introduction of errors? (this also to admit that I didn't read them all ... :-]

[0rlych1kk4]

fwiw, LGTM; see 2 small separate comments and one basic question: Did all these .yml files get manually created? If so, would it be worth while considering a script to re-do them as/when the need arises to limit the possibility for the introduction of errors? (this also to admit that I didn't read them all ... :-]

Yes, the 30 META files were created from the parameter-set pattern rather than from a committed generator. I agree a small generator would make updates safer and reduce copy/paste errors. If you think that would be useful here, I can add one under integration/liboqs/ that generates the META files from the 15 parameter sets × 2 PRGs and verify that it reproduces the current files exactly.

[baentsch]

If you think that would be useful here

Again, just my personal preference (of automating as much as possible to eliminate possible errors in the future. But AI may be an alternative to this :-)

[0rlych1kk4]

If you think that would be useful here

Again, just my personal preference (of automating as much as possible to eliminate possible errors in the future. But AI may be an alternative to this :-)

Understood. I’ll keep the generator as a possible follow-up rather than expanding this PR further.

[paschal533]

@0rlych1kk4 two things, and neither is a request to change this PR. I know you want to keep it to the integration.

Constant time. On liboqs #2582 you said you'd raise the linsys.c constant-time question with the QR-UOV maintainers. Did that come up when the team joined the status call? Once liboqs' extended tests ran valgrind over QR-UOV, they flagged three secret-dependent spots. These are now recorded as known issues on 0rlych1kk4/liboqs#1:

• the pivot search in linsys_lu_decompose
• gf_inv's table lookup
• the branch in qruov_common_canonicalize_s

For gf_inv I have a patch that computes a^(q-2) instead: https://github.com/paschal533/round3/tree/fix/ct-linsys. It's checked exhaustively against the table for q = 7, 31 and 127, and all 30 KATs are byte-identical on ref, opt and avx2. canonicalize_s is next and small. The LU is a real change to your linear algebra, so I'd rather hear how the team wants it handled before touching it.

opt stack, namespacing and wipes. https://github.com/paschal533/round3/tree/fix/review-findings has 8 commits against 36e9a7e:

• the fix for liboqs #2598, which is stack exhaustion; details are on the issue
• 11 un-namespaced functions in opt/emi_transform_gen.c, which make a shared build with two opt schemes fail with duplicate symbols
• key-generation buffers holding S times public data that were never wiped

Sign and verify don't allocate, given @baentsch's point about alloc/free per sign. Only keygen uses the heap. KATs are unchanged there too.

Would you like these as a follow-up PR against qruov/round3 once this one lands, or would the QR-UOV team rather take them another way?

[0rlych1kk4]

@0rlych1kk4 two things, and neither is a request to change this PR. I know you want to keep it to the integration.

Constant time. On liboqs #2582 you said you'd raise the linsys.c constant-time question with the QR-UOV maintainers. Did that come up when the team joined the status call? Once liboqs' extended tests ran valgrind over QR-UOV, they flagged three secret-dependent spots. These are now recorded as known issues on 0rlych1kk4/liboqs#1:

• the pivot search in linsys_lu_decompose
• gf_inv's table lookup
• the branch in qruov_common_canonicalize_s

For gf_inv I have a patch that computes a^(q-2) instead: https://github.com/paschal533/round3/tree/fix/ct-linsys. It's checked exhaustively against the table for q = 7, 31 and 127, and all 30 KATs are byte-identical on ref, opt and avx2. canonicalize_s is next and small. The LU is a real change to your linear algebra, so I'd rather hear how the team wants it handled before touching it.

opt stack, namespacing and wipes. https://github.com/paschal533/round3/tree/fix/review-findings has 8 commits against 36e9a7e:

• the fix for liboqs #2598, which is stack exhaustion; details are on the issue
• 11 un-namespaced functions in opt/emi_transform_gen.c, which make a shared build with two opt schemes fail with duplicate symbols
• key-generation buffers holding S times public data that were never wiped

Sign and verify don't allocate, given @baentsch's point about alloc/free per sign. Only keygen uses the heap. KATs are unchanged there too.

Would you like these as a follow-up PR against qruov/round3 once this one lands, or would the QR-UOV team rather take them another way?

Thanks for digging into these. I agree these should stay separate from the integration PR.
For the constant-time findings, I’d prefer the QR-UOV maintainers to decide the approach for the LU change before we modify that part of the implementation. The gf_inv and canonicalization changes also make sense as follow-up upstream work once the integration lands.

The stack-usage issue, namespacing fixes, and keygen wipes likewise look appropriate for a separate follow-up PR against qruov/round3.

Thanks also for confirming that sign/verify don’t allocate and that the heap usage is limited to keygen.

[0rlych1kk4]

Hi @baentsch , do you know who on the QR-UOV side is expected to review #1, or whether there’s an expected timeline for that review?
The liboqs integration is otherwise ready to move forward, and once the upstream PR lands I can switch the temporary fork pin in #2582 to the official QR-UOV repository/commit.

[baentsch]

Hi @0rlych1kk4 , no I have no idea. I had hoped to establish a link between all involved participants in the call on Tuesday, but the QR-UOV Team didn't seem to have a GH account and your microphone didn't work. I see two ways forward: We manage to get the upstream team to get to use GH or we establish email communication between you and the QR-UOV Team. The former is clearly preferable but the latter may be the only way to move forward. Tagging @RodriM11 to establish the email contact that only he has with the QR-UOV team (making the problem with this approach obvious: Only a subset of the required people get the information -- in this case, no-one, so far :].

[RodriM11]

Tagging @RodriM11 to establish the email contact that only he has with the QR-UOV team (making the problem with this approach obvious: Only a subset of the required people get the information -- in this case, no-one, so far :].

How to proceed is something I would like to discuss at the next Status Meeting. I believe the QR UOV people will have to wait until the date they presented at Tuesday's SM before being part of the inclusion effort. But IMO we could proceed with the PR in liboqs pinned to @0rlych1kk4 's fork (since licensing does not generate any problems) and integrate it in the official repo once they have been allowed on their side.

[0rlych1kk4]

Tagging @RodriM11 to establish the email contact that only he has with the QR-UOV team (making the problem with this approach obvious: Only a subset of the required people get the information -- in this case, no-one, so far :].

How to proceed is something I would like to discuss at the next Status Meeting. I believe the QR UOV people will have to wait until the date they presented at Tuesday's SM before being part of the inclusion effort. But IMO we could proceed with the PR in liboqs pinned to @0rlych1kk4 's fork (since licensing does not generate any problems) and integrate it in the official repo once they have been allowed on their side.

Thanks, that makes sense. I’m fine with proceeding in liboqs using the current fork pin if that’s the agreed path, and I can switch it to the official QR-UOV repository/commit once their upstream integration is available.