2023

[baentsch]

This is to foster a discussion on priorities for 2023: What releases shall be targeted for when? What shall they contain?

Initial thoughts:

• Completion of 0.8.0 (update all algs to latest level): By when?
• Addition of LMS/XMSS (i.e., finalizing Addition of stateful hash-based signatures #1275 and adding it to downstream projects)
• Update all integrations to current IETF spec drafts: OQS is quite a bit "behind" regarding OpenSSH (Update hybrid key exchange format to match Internet-Draft openssh#66), Composites/Hybrid (see e.g., specs at the "PQ" section at https://wiki.ietf.org/en/meeting/115/hackathon), possibly others as well: Taking stock of specs and deciding which ones we want to support would be good.

[ashman-p]

XMSS/LMS: For the OpenSSL components (version 3.x and 1.1.1x) seems like there will be need for a way to mark/update the status of the private key. Has that been discussed yet?

[baentsch]

there will be need for a way to mark/update the status of the private.

I'm not sure I understand this statement: Could you please elaborate somewhat? Maybe a pointer to specific OpenSSL code structures could clarify even better.

[ashman-p]

Sorry, i meant to say 'private key'. In the case for one-time use.

[baentsch]

OK -- then I get that, thanks. What do you mean by "discussed yet", then? Within the OQS team? Within the OpenSSL community? My personal answer is "not that I'm aware of" (whatever that's worth). But it seems like a solved issue (albeit details are scarce after a superficial read): http://www.amphawa.eu/data/icmu-paper.pdf.

[ashman-p]

I was just wondering if there was already any design anywhere around handling updates of keys or stateful info.
I now think that it maybe something that can be addressed easier in the provider space in OpenSSL 3.0.

[baentsch]

it maybe something that can be addressed easier in the provider space in OpenSSL 3.0.

Providers (need to) have clean entry/exit points for (sig) operations; but that part is also pretty well encapsulated in OpenSSL111. In either case, if the library implementing XMSS and friends has some OQS-like/-enhancing API to be called to handle persistence (itself, e.g., with FILE operations), it might be very simple indeed as an extension "around" the oqs-provider code for this.

[dstebila]

I agree with your priorities, Michael. I would place the algorithm updates and the corresponding liboqs 0.8.0 as the highest priority. It would be nice if we achieve that by the end of March, perhaps? And then the work on hybrid updates is also quite important but can take place in parallel.

[ashman-p]

Hi Folks,
What are the steps to begin committing LMS code here? I noticed the XMSS branch. Should i create PRs to that branch?
Thanks,
Norman

[baentsch]

Hi Norman,

What are the steps to begin committing LMS code here? I noticed the XMSS branch. Should i create PRs to that branch?

No, that branch is stale. I'd suggest you create your own. Our convention is to prepend its name with your name's initials (reminder to myself to delete "mb-upstream-patch" :)

Looking forward to that code, --Michael

[ashman-p]

Well, I created a fork based on the XMSS branch to leverage what there. And since I guess I will eventually need write permission in order to commit. In the mean while I have a couple of commits I wanted to put out. PR at....
ashman-p#1