-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to change the default PQ KEX algorithm of OQS-chromium? #100
Comments
You have hit on a shortcoming of OQS-chromium: No-one got around to implementing #52. If you need this feature and would have time to do this, we'd be very glad to receive a PR for this. Presently the only way to set the acceptable client algorithms is to build the |
I see. Thank you for your response.
Thanks for the invitation! Unfortunately I'm more like a researcher than a developer.😅 Not really good at programming. I'm doing a proof of concept project for my company which is setting an OQS enabled reverse proxy in front of all the company's servers to provide quantum safe front end connection.
Does this mean once I built the chromium I can no longer change it anymore? Kind regards, |
In my view, a good researcher (still consider myself one) shouldn't shy back from understanding others' code to give it new capabilities (call it "source code archaeology" and it's a scientific undertaking :-)
Yes. Thus it would be prudent to include all QSC algorithms your company servers would want to support: This is just a list: The more complete it is, the more algorithms your QSC-chromium build can support. It's only getting slightly more inefficient with an extremely long list of algorithms.
Yes. If you successfully built chromium all you (should) need to do is a re-build (after changing the list): The build system should take care of the rest. |
Totally agree. Maybe I should put it another way, I should say coding is my weakness and I'm still learning to improve it. But just consider what I am currently capable of I would say that the task is too hard for me. 😅😅
I see. Thank you very much sir. This is very clear and helpful. I will rebuild it and choose a proper subset of the algorithms. |
All right. But skills change over time and it'd be great if you could see this as a challenge to grow your skills on and help us resolve #52.
Good to hear. I'd then be glad to hear if this worked and we can close this issue. In any case, thanks for making us aware of some shortcomings in our documentation: We improved that accordingly. |
Sure. May I ask is there any information I can dig in to do this? I might start with researching about how to build this feature first. But no guarantee of completion cuz this task is apparently beyond my might. 😅😅
Sure, I will get back to you once I've done this. Considering my testing environment, it might be next week. |
Sorry, I don't know: I didn't look into that myself. I'd start with a web search on chromium design docs and probably also use |
UW. Thanks for the feedback & get well soon. |
Hi,
I have followed the instructions within the oqs-demos repository to build an OQS-enabled chromium and an OQS-enabled httpd server.
I found out that due to the chromium currently doesn't support curves option like the command line, it will use the default algorithm when I issue a HTTP request to my httpd server from it.
So if I configure my server only support algorithm "kyber512", the chromium will return the error page as shown below.
I have read the implementation notes of the BoringSSL saying that the client can use the
SSL_CTX_set1_curves_list
call to override this. But I can't find any instructions about how to actually do this.Is that possible can anyone provide some information or instructions about how to do this?
Kind regards,
Ray
The text was updated successfully, but these errors were encountered: