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

feat(ciphers): AES encryption #102

Merged
merged 37 commits into from
Jul 2, 2024
Merged

Conversation

eightfilms
Copy link
Contributor

@eightfilms eightfilms commented Jun 26, 2024

Partially addresses #95

It changes the following:

  • Adds an implementation of AES encryption using the SymmetricEncryption trait
  • note that decryption remains unimplemented - will add it as a follow up PR after this undergoes review and is merged

TODOs:

  • doc comments where necessary
  • richer readme like in other places
  • cleanup code, debug statements, etc.

@eightfilms eightfilms force-pushed the bing/aes-encryption branch 2 times, most recently from d201f85 to 408c607 Compare June 28, 2024 01:31
@eightfilms
Copy link
Contributor Author

Going to rebase my work based on #101

@eightfilms eightfilms force-pushed the bing/aes-encryption branch 2 times, most recently from b5d929c to b4cefae Compare June 29, 2024 11:53
@eightfilms eightfilms marked this pull request as ready for review June 29, 2024 12:02
@eightfilms
Copy link
Contributor Author

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

@Autoparallel
Copy link
Contributor

Excited to review this. May not be able to until Sunday night or Monday.


For decryption, we take the inverses of these routines:

TODO
Copy link
Contributor

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.

Copy link
Contributor Author

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)

Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor

@0xJepsen 0xJepsen left a 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]_.
Copy link
Contributor

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

Copy link
Contributor

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?

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

src/encryption/symmetric/aes/mod.rs Show resolved Hide resolved
Copy link
Contributor

@Autoparallel Autoparallel left a 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]_.
Copy link
Contributor

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?

src/encryption/symmetric/aes/mod.rs Show resolved Hide resolved
Comment on lines +33 to +38
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 }
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Collaborator

@lonerapier lonerapier left a 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 {
Copy link
Collaborator

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)

Copy link
Contributor Author

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.

@eightfilms
Copy link
Contributor Author

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)

@Autoparallel
Copy link
Contributor

@eightfilms I'm game to merge this and then handle a followup PR addressing our comments here.

Can you:

  • Make issues based off those comments
  • Resolve conflicts here?

Then I will merge :)

@eightfilms eightfilms force-pushed the bing/aes-encryption branch from 1a0d696 to d6b7220 Compare July 1, 2024 23:39
@eightfilms eightfilms force-pushed the bing/aes-encryption branch from d6b7220 to f0e38d6 Compare July 1, 2024 23:42
This was referenced Jul 1, 2024
@eightfilms
Copy link
Contributor Author

eightfilms commented Jul 1, 2024

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

@0xJepsen
Copy link
Contributor

0xJepsen commented Jul 2, 2024

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

@eightfilms
Copy link
Contributor Author

Yeah sounds good! Thanks @0xJepsen

@0xJepsen 0xJepsen merged commit 55fb8b2 into pluto:main Jul 2, 2024
5 checks passed
@eightfilms eightfilms deleted the bing/aes-encryption branch July 2, 2024 08:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants