-
Notifications
You must be signed in to change notification settings - Fork 145
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
Add optional support for the AEGIS cipher suites #478
Conversation
There's probably a way for Unfortunately, I'm not familiar at all with /cc @victorstewart |
i will gladly write the automatic build code today 🤩. i can't wait to play with this in QUIC. |
Awesome, thank you! |
that's done i sent you a PR. what do you think about adding experimental support for x2 so we can play with that too? |
Is it possible to add a hardware-agnostic implementation of AEGIS to minicrypto? That would help experimenting with AEGIS on platforms like Arduino, for which the current options are not very appealing. |
Do you mean adding an AEGIS implementation directly to the |
AEGIS-128X/256X are not in the spec and don't have IANA identifiers yet. One thing at a time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the pull request. This is exciting!
Changes look good, I only have nitpicks.
At first glance, it did seem odd to me to have the definitions in libaegis.h and including them in openssl.c. But that makes sense, a TLS cipher suite is a combination of an AEAD cipher and a hash function. We have to borrow a hash function from somewhere.
As to @huitema's point of having aegis support on the side of minicrypto, I think it makes sense. We can add a source file that just includes libaegis.h and combines the AEAD ciphers with the ptls-minicrypto sha objects. But I would not mind that being deferred to a separate pull request.
PS. For CI, am I correct to understand that I should be adding https://github.com/jedisct1/libaegis to the CI image so that we can test the aegis integration? @jedisct1 |
@kazuho What would be the best way to add |
I do not think we need to add libaegis to deps/. Our CI (see .github/workflows/ci.yml and misc/docker-ci.mk) uses a Docker image built using https://github.com/h2o/h2o/blob/master/misc/docker-ci/Dockerfile.ubuntu2004. Assuming that we want to test aegis integration, I am wondering how I should change this Dockerfile. I would assume what I'm expected to do is fetch and build the HEAD of https://github.com/jedisct1/libaegis in the Dockerfile and set |
In that case, yes, you can build and install it in the Docker image from the |
Thanks! I've added libaegis to the CI image (h2o/h2o#3268), and pushed a commit that turns on aegis in CI (2897b64). Please feel free to pick the commit to this PR. However, the CI is failing. Could you please take a look at it? You can click on the CI page and see the raw logs, I think that'd help. |
Support for |
Hi @kazuho ! Could you update the docker image with the current |
i think what makes most sense is what i wrote in my build PR that if aegis is enabled, but no libaegis source code directory (as requested by Frank) is specified and find_package is unable to find libaegis installed on any paths, that it automatically downloads and builds libaegis from GitHub. |
@jedisct1 Thank you for the changes! I've updated the CI image, but we are seeing issues. It seems to me that the aegis backends of openssl and minicrypto contradict to each other, as the "picotls" subtest is passing but "minicrypto vs." and "vs. minicrypto" are failing. Could you look into it? |
Thank you! Yes, I'm looking into it. |
This adds the following TLS 1.3 suites: - `TLS_AEGIS_256_SHA384 (0x13, 0x07)` - `TLS_AEGIS_128L_SHA256 (0x13, 0x06)` Requires `libaegis`.
Alright. Rebased and squashed. CI's finally happy. 🎉 The fact that |
@jedisct1 Thank you for the fix! I think all the code is ready, I only have one question. Do you think support for aegis should be enabled by default? The thing is that I am considering of introducing The idea is that applications can continue using Does that make sense to you? |
@kazuho Yes, introducing a distinct cipher suite sounds good. |
Is there any other changes you would like, @kazuho ? |
Thank you for the changes! Let's merge. |
[ci] for h2o/picotls#478, add libaegis to CI image
This adds the following TLS 1.3 suites:
TLS_AEGIS_256_SHA384 (0x13, 0x07)
TLS_AEGIS_128L_SHA256 (0x13, 0x06)
Requires
libaegis
, and currently OpenSSL/BoringSSL for the key derivation.