-
Notifications
You must be signed in to change notification settings - Fork 25
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
feat(ciphers): AES encryption #102
Conversation
d201f85
to
408c607
Compare
Going to rebase my work based on #101 |
b5d929c
to
b4cefae
Compare
Ok, I think this should be ready for a look. Preparing the docs took a bit longer than expected - let me know if anything is unclear |
Excited to review this. May not be able to until Sunday night or Monday. |
|
||
For decryption, we take the inverses of these routines: | ||
|
||
TODO |
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.
Complete or add more detail.
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.
Ah yeah, was thinking to leave decryption for a followup PR - apologies for not being clear about that, but I could also complete it within the same PR (if that's preferable)
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'm fine either way
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.
Filed an issue for decryption: #119
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.
This looks great to me! I would maybe add this to the root README
|
||
The **KeyExpansion** algorithm takes a 128/192/156-bit key and turns it into 11/13/15 round keys respectively of 16 bytes each. The main trick to key expansion is the fact that if 1 bit of the encryption key is changed, it should affect the round keys for several rounds. | ||
|
||
Using different keys for each round protects against _[slide attacks]_. |
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.
Can we link a resource on slide attacks? Would be nice to write a test for them at some point if it's not too crazy
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.
Yes i 100% agree. An example of this would be amazing!
If you don't do it in this PR (which, by no means, do you have to) can you make an issue?
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.
Filed an issue: #120 (comment)
|
||
### Decryption | ||
|
||
TODO |
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.
Either address the todo or elaborate in a comment.
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.
Filed an issue for decryption: #119
the key and the ciphertext as part of the *confusion* property. | ||
|
||
During substitution, a byte is interpreted as a polynomial and | ||
mapped to its multiplicative inverse in [Rijndael's finite field][Rijndael ff]: GF(2^8) = GF(2)[x]/(x^8 + x^4 + x^3 + x + 1). |
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.
Awesome!
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'm good to merge this! Would love to see the decryption done :)
|
||
The **KeyExpansion** algorithm takes a 128/192/156-bit key and turns it into 11/13/15 round keys respectively of 16 bytes each. The main trick to key expansion is the fact that if 1 bit of the encryption key is changed, it should affect the round keys for several rounds. | ||
|
||
Using different keys for each round protects against _[slide attacks]_. |
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.
Yes i 100% agree. An example of this would be amazing!
If you don't do it in this PR (which, by no means, do you have to) can you make an issue?
impl<const N: usize> std::ops::Deref for Key<N> | ||
where [(); N / 8]: | ||
{ | ||
type Target = [u8; N / 8]; | ||
|
||
fn deref(&self) -> &Self::Target { &self.inner } |
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.
Why do we need Deref
?
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.
Ah it's really just so we don't have to do key.inner
. I think we only use it twice so I can actually remove this impl, it isn't more convenient and adds unnecessary lines
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.
All good! Keep it in if you want, I just wasn't quite sure where it was being used.
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.
Amazing work sir! Just one question, are we adding BlockCipher
trait in a followup PR?
{ | ||
/// Performs the cipher, with key size of `N` (in bits), as seen in Figure 5 of the document | ||
/// linked in the front-page. | ||
fn aes_encrypt(plaintext: &[u8; 16], key: &Key<N>, num_rounds: usize) -> Block { |
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.
It would be good to have result instead of assert (totally optional)
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.
we can, but imo some of the asserts can/should coexist alongside Result
usage, since they're asserting some of the invariants in the procedure (such as round keys being used up by the end of the encryption). Will see how I can refactor to have less unwrap()
s.
Thanks for the reviews! Will implement decryption and an example of a slide attack within this same PR and request again very soon. Alternatively we can merge and leave that for a followup PR (whichever is preferable) |
@eightfilms I'm game to merge this and then handle a followup PR addressing our comments here. Can you:
Then I will merge :) |
1a0d696
to
d6b7220
Compare
expanded key is not really a good name; since the key expansion actually outputs a vector of `Word`s, where each 4-word chunk is used as a round key.
d6b7220
to
f0e38d6
Compare
Oops, I messed up the commit history (i blame my unfamiliarity with jj), but all I really did was resolve the merge conflict. Sorry for the mess, i'll see if i can fix it |
I think it's okay! If thats all thats left we can git this one in |
Yeah sounds good! Thanks @0xJepsen |
Partially addresses #95
It changes the following:
SymmetricEncryption
traitTODOs: