-
Notifications
You must be signed in to change notification settings - Fork 7
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
Simplify AES module structure #79
Changes from 7 commits
53d6e68
6b1af4b
8c14010
302d249
9e1b9a0
c46fa18
0244aa4
6430913
d736d81
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. note: I constrained AES-GCM-SIV to just use AES256, which is effectively what it was doing before (due to the type constraint below). I think a nicer option would be to write GCM-SIV in terms of a I also don't think this works right now; I tried dropping a test vector in but it didn't work in either the before or after version and I chose not to spend much time debugging right now. There are some weird constraints here (for example, the RFC allows the associated data to be 0-64 bytes long; here it's restricted to a minimum of 44 bytes?). I think all of this is better suited to a separate issue, which I'm happy to write up. This work does not make anything worse, at least. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On second look, I misread the comparison in L22. This previously supported both AES versions, but now it only supports one. I'll take another pass and try to fix it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
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.
question: I am trying to partially initialize the functor here -- set the
K
andE
parameters and leave the others (T
,AAD
,IV
) up to the caller. This compiled the way I expected, but below on L40 & L41, I wasn't able to specify those other parameters when I called it; I had to give explicit types to the parameters themselves. E.g. I thought I could dobut I couldn't get the bracket notation to compile. Instead, I had to specify the type of the IV where I declared it:
Why is that the case? And does this still do what I want it to do (instantiate AES-GCM for a fixed key size and arbitrary IV, plaintext, and tag length)?
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.
I think this has something to do with the fact that the wrapper API here isn't actually a functor. I guess the bracket notation only operates directly on a functor, and if I wanted to be able to explicitly specify these types I'd have to make AES_GCM be a functor as well with the additional parameters defined. Maybe this can be done in #80 if we think it's useful.