OQS Enabled Envoy Contribution

[dr7ana]

We would like to contribute a compiled and functional fork of envoy v1.23.1 enabled with post-quantum encryption.

The source code repository can be found here. In the README, build instructions and a docker image are also listed. Three of the example demos that were provided with the original envoy source code have been modified to use the post-quantum implementation. They can be found in the examples folder in the source directory.

In order to make this work, I forked the OpenQuantumSafe implementation of BoringSSL, and updated the master-with-bazel branch to compile the latest BSSL code. This is stored here.

We will be presenting this project, plus a post-quantum enabled istio build, at KubeCon on October 28th. As part of the presentation, we will be inviting the open-source community to continue work on the envoy and istio projects.

Please let me know if it would be OK to submit a pull request for the boringssl fork to the bssl-oqs repo and the envoy demo to the oqs-demos repo, and do not hesitate to e-mail me with any questions or comments.

Thank you very much,

Daniel Rouhana danielrouhana@pm.me

[baentsch]

Thanks very much for letting us know and for using our work to do such comprehensive "cloud quantum-safety enablement" effort: Well-deserved KubeCon presentation!

Please allow some questions to help me understand your goals before giving insufficiently well-informed responses:

As part of the presentation, we will be inviting the open-source community to continue work on the envoy and istio projects.

Is the goal here to get your changes to envoy and istio integrated to the upstream projects or should they indeed be kept (and maintained) separately in Post-Quantum-Mesh?

Please let me know if it would be OK to submit a pull request for the boringssl fork to the bssl-oqs repo

You presently have done your BSSL changes in Post-Quantum-Mesh: If istio and envoy shall be retained separately as per the above (?) why not also oqs-BSSL? In turn, if your goal is to stop maintaining Post-Quantum-Mesh (?) why not move all sub-projects to open-quantum-safe?

We would like to contribute a compiled and functional fork of envoy v1.23.1 enabled with post-quantum encryption.

Why would you want to contribute a compiled build? Our goal in oqs-demos is to provide all code and instructions for QSC-enabling the components demo'd, including the Dockerfile. This way, anyone interested in the integration can learn and maintain/evolve the entire code base even if the original author moved on to other projects. A compiled contribution will become stale pretty quickly as all constituent projects move on.

Please take a look how we structured all other demos in oqs-demos: They contain explanations/diffs for the constituent components (or reference to an open-quantum-safe subproject), a Dockerfile for building the full demo and two README's: One for builders and one for users of the image.

Thus, without more input as per the questions above, my immediate suggestion would be for you to do a PR to oqs-demos comprising of Dockerfile (and builder&user READMEs) and maintain all sub-project code bases separately.

[dr7ana]

Thank you for the questions!! I will try to answer them individually

Is the goal here to get your changes to envoy and istio integrated to the upstream projects or should they indeed be kept (and maintained) separately in Post-Quantum-Mesh?

To be honest, I'm still a post-bacc student, and this is the first open-source project I've worked on. I'm happy for anybody to do anything with this work to be quite honest. "Post-Quantum Mesh" is just the github org we're using to keep everything aggregated, and to be honest the name was originally a placeholder. Please do not hesitate to suggest better ideas

You presently have done your BSSL changes in Post-Quantum-Mesh: If istio and envoy shall be retained separately as per the above (?) why not also oqs-BSSL? In turn, if your goal is to stop maintaining Post-Quantum-Mesh (?) why not move all sub-projects to open-quantum-safe?

I apologize for not explaining clearly the first time. The boringssl-oqs I modified is actually this, the master-with-bazel branch of the OQS fork of Boringssl. In my early attempts at porting Envoy with the OQS library, I noticed that the master-with-bazel branch hadn't been updated since 2019. Also, the build files didn't actually build liboqs.a as a final library (confirmed this by grepping through envoy built with the 2019 commit).

I would be more than happy to continue helping maintain this project, assuming anyone cares to keep working on it 😄 This probably wasn't clear as I didn't explain well in my first post, but I wanted to offer the updated boringssl-oqs I modified to update the master-with-bazel branch of the Boringssl repository.

Why would you want to contribute a compiled build? Our goal in oqs-demos is to provide all code and instructions for QSC-enabling the components demo'd, including the Dockerfile. This way, anyone interested in the integration can learn and maintain/evolve the entire code base even if the original author moved on to other projects. A compiled contribution will become stale pretty quickly as all constituent projects move on.

I understand! Thank you very much for explaining. Just to clarify, the source code here is not compiled, but can be built from source locally. My thoughts behind contributing the modified source code would be for any continued development future users may want to make for their specific use-case.

The only compiled product is a docker image I pushedto hub, but I see now that the Dockerfile I used for this is what you're looking for for oqs-demos. Please correct me I'm misunderstanding

[baentsch]

I would be more than happy to continue helping maintain this project

Glad to hear that!

Please correct me I'm misunderstanding

You are not misunderstanding. We'd be glad to receive a PR for this dockerfile incl. explanation what it does (README.md) and how it can be used (USAGE.md).

Ideal would be an addition to the CI such that it is automatically built, tested and pushed to docker hub. See examples in https://github.com/open-quantum-safe/oqs-demos/blob/main/.circleci/config.yml. But I'd also be glad to add such CI code after you did the PR.

[dr7ana]

@baentsch Sorry for lagging on this, PR created!

[baentsch]

Thanks again for the contribution! Issue closed as #161 has merged.