Add explicit initialization vector to aes_encrypt()

[numberten]

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]

My proposed solution for #627.

[ipapapa]

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]

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!