Skip to content
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

Implement AES-GCM-SIV #16721

Closed
beldmit opened this issue Sep 30, 2021 · 16 comments
Closed

Implement AES-GCM-SIV #16721

beldmit opened this issue Sep 30, 2021 · 16 comments
Labels
branch: master Merge to master branch triaged: feature The issue/pr requests/adds a feature
Milestone

Comments

@beldmit
Copy link
Member

beldmit commented Sep 30, 2021

AES GCM SIV is specified in RFC 8452

@beldmit beldmit added the issue: feature request The issue was opened to request a feature label Sep 30, 2021
@t8m t8m added branch: master Merge to master branch triaged: feature The issue/pr requests/adds a feature and removed issue: feature request The issue was opened to request a feature labels Sep 30, 2021
@t8m t8m added this to the Post 3.0.0 milestone Sep 30, 2021
@dylan7581
Copy link

Hello,

We are a team of new contributors whose goal is to answer security issues on open source projects.

In response to your ticket, we tried to implement AES-GCM-SIV in OpenSSL inspired by what was done for AES-GCM. Here you will find our implementation of this algorithm:
https://github.com/Project-Opensource/AES-GCM-SIV

Unfortunately, due to a lack of knowledge of the OpenSSL architecture (with the providers directory), we were unable to integrate it correctly so that it was available for use.

In the hope that our contribution will advance the problem,

Contribution by Project Opensource.

@tmshort
Copy link
Contributor

tmshort commented Mar 10, 2022

I can't speak for the OMC, but there might be some licensing issues here. Specifically, OpenSSL uses the Apache 2.0 license and I'm not seeing any formal licensing in that repository. Then there's the matter of CLAs.

If those issues are resolved, I'd be willing to look at this; I was the one that ported the AES-SIV code.

Ref: RFC-8452

@mattcaswell
Copy link
Member

I'm not seeing any formal licensing in that repository. Then there's the matter of CLAs.

All contributors who were involved in writing the code would have to submit CLAs to us (https://www.openssl.org/policies/cla.html). We would also need some statement formally contributing the code to us. Usually when code is contributed it occurs through a PR which is deemed as sufficient indication that the authors are contributing the code - but there is no PR here. The licensing of the original code is not really a problem: if the authors sign a CLA, and formally contribute the code under that CLA, then the CLA allows us to relicence it to Apache 2.

@tmshort
Copy link
Contributor

tmshort commented Mar 11, 2022

The licensing of the original code is not really a problem

I was mostly checking to see if there was already Apache, BSD, MIT or GPL licensing attached. I suspect that any GPL flavor would be an issue.

@tmshort
Copy link
Contributor

tmshort commented Mar 11, 2022

Actually, it looks as though they applied an Apache 2.0 license on it: Project-Opensource/AES-GCM-SIV@5ac1d57

@t8m
Copy link
Member

t8m commented Mar 11, 2022

We would still need CLAs signed.

@dylan7581
Copy link

Hello,

We sent the signed CLAs by email.

@tmshort
Copy link
Contributor

tmshort commented Mar 11, 2022

@t8m @mattcaswell unless someone else really wants to do this, feel free to assign this to me.

@dylan7581
Copy link

dylan7581 commented Mar 12, 2022

Hello,

we sent our CLA to the email address: legal@opensslfoundation.org, but we received an email telling us this:
"We were unable to deliver your mail. The recipient's mail system refused to accept a connection from your mail system despite multiple attempts to deliver your mail."

image

How should we proceed ?

@paulidale
Copy link
Contributor

That's the correct address, I didn't see anything come in. No idea why :(

@levitte, any idea?

@dylan7581
Copy link

We also tried with another mail service, but the result is the same. : -(
Do you have a temporary solution that could work around this problem?

@paulidale
Copy link
Contributor

@levitte??

@beldmit
Copy link
Member Author

beldmit commented Mar 29, 2022

Are there any updates regarding the CLA status?

@paulidale
Copy link
Contributor

Could you please resend the CLAs to legal@opensslfoundation.org, we had some server problems recently.

@dylan7581
Copy link

Email is working fine again!

@tmshort
Copy link
Contributor

tmshort commented Apr 26, 2022

What's the status of this?

tmshort added a commit to tmshort/openssl that referenced this issue Jul 1, 2022
Fixes openssl#16721

This uses AES-ECB to create a counter mode AES-CTR32 (32bit counter, I could
not get AES-CTR to work as-is), and GHASH to implement POLYVAL. Optimally,
there would be separate polyval assembly implementation(s), but the only one
I could find (and it was SSE2 x86_64 code) was not Apache 2.0 licensed.

This implementation lives only in the default provider; there is no legacy
implementation.

The code offered in openssl#16721 is not used; that implementation sits on top of
OpenSSL, this one is embedded inside OpenSSL.

Full test vectors from RFC8452 are included, except the 0 length plaintext;
that is not supported; and I'm not sure it's worthwhile to do so.
tmshort added a commit to tmshort/openssl that referenced this issue Jul 22, 2022
Fixes openssl#16721

This uses AES-ECB to create a counter mode AES-CTR32 (32bit counter, I could
not get AES-CTR to work as-is), and GHASH to implement POLYVAL. Optimally,
there would be separate polyval assembly implementation(s), but the only one
I could find (and it was SSE2 x86_64 code) was not Apache 2.0 licensed.

This implementation lives only in the default provider; there is no legacy
implementation.

The code offered in openssl#16721 is not used; that implementation sits on top of
OpenSSL, this one is embedded inside OpenSSL.

Full test vectors from RFC8452 are included, except the 0 length plaintext;
that is not supported; and I'm not sure it's worthwhile to do so.
sftcd pushed a commit to sftcd/openssl that referenced this issue Sep 24, 2022
Fixes openssl#16721

This uses AES-ECB to create a counter mode AES-CTR32 (32bit counter, I could
not get AES-CTR to work as-is), and GHASH to implement POLYVAL. Optimally,
there would be separate polyval assembly implementation(s), but the only one
I could find (and it was SSE2 x86_64 code) was not Apache 2.0 licensed.

This implementation lives only in the default provider; there is no legacy
implementation.

The code offered in openssl#16721 is not used; that implementation sits on top of
OpenSSL, this one is embedded inside OpenSSL.

Full test vectors from RFC8452 are included, except the 0 length plaintext;
that is not supported; and I'm not sure it's worthwhile to do so.

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from openssl#18693)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
branch: master Merge to master branch triaged: feature The issue/pr requests/adds a feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants
@t8m @mattcaswell @tmshort @beldmit @paulidale @dylan7581 and others