Re: [openpgp] Reducing the meta-data leak

[Bryan Ford <[e-mail]>]

Thanks Ian for the feedback! (and the patience :) )

On Nov 8, 2015, at 1:02 PM, ianG <[e-mail]> wrote:
> On 7/11/2015 11:33 am, Bryan Ford wrote:
>> […]
>> So we basically have three important blobs of data to place in the file:
>> (a) the salt for the password-hashing scheme, (b) the AEAD-encrypted
>> session key encrypted using the password-hasher’s output, and (c) the
>> AEAD-encrypted file content encrypted using the session key.  Item (a)
>> needs to be encoded in the file in “cleartext” since it needs to be
>> available to the decryptor before it can decrypt anything, but
>> fortunately the salt can just be a uniformly random blob anyway (of a
>> length fixed by this well-known scheme).  So for the moment let’s just
>> put it at the very beginning of the encoded file.  Then place the
>> AEAD-encrypted session key blob (b) immediately afterwards, whose size
>> can also easily be fixed for this scheme.  This fixed-length session-key
>> blob may contain encrypted metadata in addition to the session key, such
>> as the file offset of the AEAD-encrypted file content, the (possibly
>> padded) total size of the AEAD-encrypted blob, and perhaps the size of
>> the “useful payload” within that blob after removing any padding.
> 
> I'd suggest also:
> 
> * the version number of the OpenPGP format, like v4 or whatever it is supposed to be - thus causing a stab at how we handle rollover of this format, at least of the following file content.

Indeed, that should be added (inside the blob) and is easy to add.  And the stuff inside the blob could look as much like a conventional PGP packet-stream as we like.

> * a self-MAC on the blob.  This is the proof that you've found the right password, and can proceed.  This would be calculated over the blob with the self-MAC field set to all zeroes.  Extra points if the calculation also includes the salt (a).

Since both the session-key blobs and the main file/payload blob are AEAD-encrypted, those AEAD-encrypted blobs have MACs attached to them by the AEAD algorithm.  Thus, the decryptor knows he’s got the right password when the AEAD decryption algorithm (applied to the correct session-key blob at the correct range of bytes in the file) successfully checks whatever MAC the AEAD scheme defines and returns “All’s well.”

Of course all this could be defined just as well separating the encryption for the MAC-checking, but I just thought it was easiest to go with the AEAD-based definition.

> * any primary MACs over the file data including the padding, pending those other discussions on integrity checking.

Yes.  Any payload padding gets changed, the AEAD’s MAC fails.

There’s a second-order subtlety, regarding how strongly we would want to protect against a (very) active attacker using selective corruption to “probe” the size and shape of the header region _before_ the padded payload even begins.  If some of that region is just random bits (e.g., unused hash table entries) or symmetric-key blobs for “other” recipients, then in my scheme’s basic formulation, the attacker can corrupt bits in those regions and the decryptor might still accept it, whereas the decryptor will refuse to accept it if “its” particular symmetric-key blob (or anything in the payload) gets corrupted.  Thus, a (very) active attacker who can use a decryptor as a “like/don’t-like” oracle can effectively do "corruption tomography” to learn the shape of the header area, thereby possibly learning back a bit of the metadata that we’re trying to hide.  I know of a way to enable the decryptor to check the whole header for corruption as well, but it’s a bit scarily complex and creates other tradeoffs so I haven’t decided if it’s worth the effort.  (Basically it making the header-generation scheme deterministic such that the decryptor can re-run the header-layout code and scream if anything is other than the way the encryptor “should have” done it, including the values of the [pseudo-]random bit in unused hash table entries and such.)

>> This
>> metadata will of course appear as uniform random bits to a non-recipient
>> as long as the AEAD encryption scheme is doing its job.  Finally, place
>> the AEAD-encrypted file content (c), including any padding, after the
>> encrypted session-key blob as the rest of the file.
> 
> 
> Yup.
> 
> On the remaining SM stuff, I'd like to hear that there is widespread support for this before subjecting myself to the pain.

Understandable, sorry if my text was a bit impenetrable - I realize I need to work on some better examples and diagrams. :)

B