Fog view response ciphertext length padding

[cbeck88]

This issue came out of discussion of this PR (#2252) by @samdealy which implements the "collation" operation of the fog view router, which dispatches requests to multiple workers.

The issue has to do with the following:

• ORAM works with fixed size blocks, and ETxOutRecord are usually fixed size, but across version bumps to the blockchain, they may get bigger.
• To deal with this, in the fog view enclave, we have chunks of 240 bytes for ETxOutRecord which are allocated in the oblivious hash map.

  mobilecoin/fog/view/enclave/impl/src/e_tx_out_store.rs

  Line 30 in 07d7563

  type ValueSize = U240;

  Then the first byte is reserved to mark how many bytes less than 239 are actually used by the ETxOutRecord protobuf.

  mobilecoin/fog/view/enclave/impl/src/e_tx_out_store.rs

  Line 154 in 07d7563

  value[0] = self.last_ciphertext_size_byte;

• When the user makes a request, we obliviously find the correct chunk, but then we remove this marker byte and only send back exactly the number of bytes for the real ETxOutRecord.

  mobilecoin/fog/view/enclave/impl/src/e_tx_out_store.rs

  Line 185 in 07d7563

  // Copy the data in value[1..] to result.ciphertext, resizing if needed

For the Fog view router, which has to collate the responses from several workers, intuitively it wants to use CMOVs to conceal which if any workers gave successful responses. But this is very complicated when the different workers may give differently sized responses.

• The fog view router has a new API, and Sam's idea was to leave this marker byte in when we return the ETxOutRecord to the client. This way we can always make a fixed size response, and the client can deal with removing the marker byte.

In review, we observe that:

• We probably SHOULD have made fog view always do that, and let the user remove the marker byte, because this prevents leakeages around requesting an old (v0) TxOut from occuring via the size of encrypted payloads. I think at the time I just wanted to make the API as simple as possible for the clients, but this is not that complicated, and it improves the privacy of the system.
• Otherwise we will always be leaking when someone requests an old v0 TxOut from the system.
  (I think also, during design there was uncertainty around whether and how often TxOut would be extended in real life.)
• This will also simplify the collation code in PR 2252, because the service can assume that all the chunks that come back from the workers have the same size, and it doesn't even have to think about the marker bytes.

Proposed Action items:

• We should make a change to the way that the fog view enclave (which will become the fog view worker after the fog view router project) SHOULD change the way it passes the e_tx_out_record back to the client.
• It should include the marker byte and not remove it, and always return payloads of the maximum size. This code

  mobilecoin/fog/view/enclave/impl/src/e_tx_out_store.rs

  Line 185 in 07d7563

  // Copy the data in value[1..] to result.ciphertext, resizing if needed

  should look more like the collation code which leaves the marker byte in when we return to the clients.
• The collation code can assume that all payloads returned by the workers are the same size and have the padding byte, and it doesn't have to do anything with it.
• This will prevent leakages that can occur if the service operator analyzes traffic between the router and the workers.
• This cannot be done without a breaking change to the fog view API. Until the fog router project is finished, we don't want to make any breaking changes to the fog view API, because clients in the wild are using it. So this is likely a more distant v4 item or something.