-
Notifications
You must be signed in to change notification settings - Fork 162
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
Experimental code from HACL* for AES128-GCM #18
base: main
Are you sure you want to change the base?
Experimental code from HACL* for AES128-GCM #18
Conversation
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed. If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
Thanks for the PR, do you mind signing the CLA. If you have any issues, please let me know. |
I am waiting approval from my workplace HR for the CLA.
French admin aren’t comfortable with online licenses, although I am trying to convince them its pretty standard.
They would be more comfortable if there were a specific INRIA-Facebook agreement that covered this kind of contribution.
Anyway, I am pushing them to say yes so I can sign the CLA.
In any case, I’ve licensed the code as MIT, I hope that’s consistent with the license on Fizz.
…-Karthik
On 21 Nov 2018, at 19:36, Subodh Iyengar ***@***.***> wrote:
Thanks for the PR, do you mind signing the CLA. If you have any issues, please let me know.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEtKywdTKXuw_UGbN8IXdMCXpCc60T2Dks5uxZ0tgaJpZM4Ys0EN>.
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
The CLA is now signed.
… On 21 Nov 2018, at 19:36, Subodh Iyengar ***@***.***> wrote:
Thanks for the PR, do you mind signing the CLA. If you have any issues, please let me know.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEtKywdTKXuw_UGbN8IXdMCXpCc60T2Dks5uxZ0tgaJpZM4Ys0EN>.
|
Thanks for signing the CLA. If it's not too much work, would it be possible to re-organize this as experimental/crypto instead of crypto/experimental It'd be great to have a top level directory for all experimental functions. I've also left a few review comments. Apart from that this looks great |
// get iv and init hacl | ||
auto iv = createIV(seqNum); | ||
uint8_t* keyData = const_cast<uint8_t*>(key_.key->data()); | ||
Hacl_AesGCM_NI_aes128_gcm_init(ctx, keyData, iv.data()); |
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.
do you need to modify the key here? or is it just a limitation of the hacl interface?
iobuf has a writableData() as well which will give you a non const ptr to the data
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.
const cast is fine if you dont have to change the key but its just takes a non const ptr
auto out = folly::IOBuf::create(headroom_ + inputLen + getCipherOverhead()); | ||
out->advance(headroom_); | ||
out->append(inputLen + getCipherOverhead()); | ||
auto inData = const_cast<uint8_t*>(plaintext->data()); |
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.
writableData() here will do what you want.
auto cipherData = const_cast<uint8_t*>(ciphertext->data()); | ||
|
||
auto res = Hacl_AesGCM_NI_aes128_gcm_decrypt( | ||
ctx, inputLen-16, out->writableData(), cipherData, aadLen, aad); |
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.
nit: spacing here inputLen - 16
I am preparing an update to the PR, which I will send to you over the holidays.
If we manage to get a reasonable version accepted into master/experimental by the first week of January, I’ll be able to speak about it at RWC which would be cool.
…-Karthik
On 6 Dec 2018, at 14:12, Subodh Iyengar ***@***.***> wrote:
@siyengar commented on this pull request.
In fizz/crypto/experimental/hacl/Hacl.cpp <#18 (comment)>:
> +
+void Hacl::setKey(TrafficKey tk) {
+ tk.key->coalesce();
+ tk.iv->coalesce();
+ key_ = std::move(tk);
+}
+
+std::unique_ptr<folly::IOBuf> Hacl::encrypt(
+ std::unique_ptr<folly::IOBuf>&& plaintext,
+ const folly::IOBuf* associatedData,
+ uint64_t seqNum) const {
+ Lib_Vec128_vec128 ctx[22] = {0};
+ // get iv and init hacl
+ auto iv = createIV(seqNum);
+ uint8_t* keyData = const_cast<uint8_t*>(key_.key->data());
+ Hacl_AesGCM_NI_aes128_gcm_init(ctx, keyData, iv.data());
const cast is fine if you dont have to change the key but its just takes a non const ptr
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEtKy3MKksJf2l0z8twTDsf5JJ7yLuJ1ks5u2RepgaJpZM4Ys0EN>.
|
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.
@knekritz has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
This is a first (version 0) commit of HACL* code for AES128-GCM.
The code is not yet verified.
It relies on AES-NI and PCLMUL instruction sets.
The API it provides is somewhat crude (one-shot).
Future versions of this code will be verified and will provide an incremental IOBuf-friendly interface.
This version is primarily for testing and refining the verification -> deployment workflow.