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

Add explicit initialization vector to aes_encrypt() #618

Open
wants to merge 5 commits into
base: dev
Choose a base branch
from

Conversation

numberten
Copy link

@numberten numberten commented Nov 12, 2018

aes_encrypt() now prepends one block of cryptographically strong
pseudo-random bytes to the plaintext. This block is used in the
decryption of subsequent blocks as per CBC mode of operation,
playing the role of a unique and random initialization vector by
making encryption non-deterministic.

This scheme of prepending a random block to the plaintext provides
a simpler alternative to communicating a random and unique IV between
the encryption and decryption routine (which would typically involve
sending the IV over the wire, or managing shared state between the
two routines).

numberten and others added 3 commits November 12, 2018 13:36
aes_encrypt() now prepends one block of cryptographically strong
pseudo-random bytes to the plaintext. This block is used in the
decryption of subsequent blocks as per CBC mode of operation,
playing the role of a unique and random initialization vector by
making encryption non-deterministic.

This scheme of prepending a random block to the plaintext provides
a simpler alternative to communicating a random and unique IV between
the encryption and decryption routine (which would typically involve
sending the IV over the wire, or managing shared state between the
two routines).
@numberten
Copy link
Author

My proposed solution for #627.

@ipapapa ipapapa requested a review from smukil January 17, 2019 12:40
@ipapapa
Copy link
Contributor

ipapapa commented Jan 17, 2019

If we start updating a cluster with live traffic will this break replication? We need to make sure that we can gracefully upgrade clusters to make it work properly.

@numberten
Copy link
Author

For a change like this to support incremental rollout (i.e. backwards compatibility) it might be easiest to add a new dmsg version and provide the explicit IV functionality via a branch on version.

It appears everywhere dyn_aes_encrypt(), dyn_aes_encrypt_msg(), and dyn_aes_decrypt() get called they're in the context of a dmsg, allowing them to be passed a reference to the current version.

This would require updating a cluster in two-stages:

  • first so receivers are forward compatible with the new versions
  • second so that senders can begin using the new dmsg version.

As far as I can tell there is no way for a sender to know the version of its receiver in advance.

Also interested in hearing other suggestions on ways to go about allowing incremental rollout for a change to underlying messages like this!

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.

2 participants