Encryption is currently applied in exactly one place, while wrapping the stream
of an upload request that carries an upload session with encryption metadata.
A writer that moves a blob straight into a storage policy therefore stores it
as it was, which is how a storage policy relocation ends up leaving plaintext
on a policy that has file encryption enabled.
Add RelocateBlob, which transfers the blob of an entity into another storage
policy and applies that policy's encryption setting on the way. A blob that is
already encrypted is transferred as ciphertext under its existing data key, so
relocation costs no crypto and cannot invalidate the key held by the entity. A
plaintext blob relocated into a policy with encryption enabled is encrypted
during the transfer under a freshly generated data key, which is returned for
the caller to persist onto the entity, along with an EncryptMetadata field on
RelocateEntityParameter to commit it with.
The encryption metadata is returned rather than persisted so that the plaintext
data key never has to be carried in a resumable task state, and it is stripped
from the returned value for the same reason.
Extract the stream wrapping into encryptUploadRequest so both writers share it,
and pass the request offset as the counter offset instead of a hardcoded zero.
That is a no-op today, since server side encryption only ever runs on a relayed
upload, which is forced into a single chunk starting at zero, but it keeps the
keystream aligned for any writer that starts at an offset.
Refs #3518
PLus123456
Aaron Liu
AaronLiu