Suggestions to support another solution for a demo

[Utopiah]

I suppose the pattern to support liboqs is to

1. identify where encrypted communication takes place in the code base
2. in there identify how a specific algorithm is selected
3. change, or better in the long run generalize, the selection of an algorithm
4. rely on liboqs (direct use in C or current wrappers for C++ C# Rust Python Go or Java) to encrypt/decrypt messages or if available at a higher level (e.g oqs openssl or boringssl)
5. verify that communication of messages encrypted through the new algorithm can get decrypted

If this is not correct what should be considered instead?

These is asked in terms of https://github.com/matrix-org/matrix-doc/issues/3516 to potentially demo https://github.com/matrix-org/synapse with oqs.

[baentsch]

Not being familiar with the concepts of Matrix --in fact just having read up a little about it for the first time-- I'd be inclined to say that item 3. in the list above is the most important and IMO first one to consider: Determine in general terms where which type of encryption is needed for which types of data in terms of what (only message exchanges or also metadata thereof?) needs to be protected (e.g., only integrity or truly confidentiality?).
In the context of the "quantum threat", particularly in terms of duration of protection: Is it possible for attackers against Matrix to obtain/store (encrypted) records of data today and attack them in the future (say if a real quantum computer appears)? If so, I'd think about an "archive" concept that may rely on liboqs. But again, this is just scratching the surface.
Also pretty relevant is to know about performance and speed requirements for an application: There's wide variance between different QSC algorithms. Also to consider: Not all algorithms in liboqs might remain supported in the future (say, if NIST or anyone else finds flaws in them -- hence again the explicit link here to the OQS limitations disclaimer).

All told, in my eyes the list above is OK for a first "stock taking" or rough evaluation to do an initial demo (e.g., to evaluate the performance impact of using QSC algorithms), but needs to be extended substantially if one wants to truly address the "quantum threat" for real -- particularly if message exchange is required with many different & diverse parties as seems to be the case with Matrix.

[baentsch]

Closing issue due to inactivity. Please open a new issue if hitting problems with this integration. If the integration works, please let us know: We'd also be glad to showcase it (or receive a PR).