Re: [openpgp] Reducing the meta-data leak

[ianG <[e-mail]>]

On 7/11/2015 11:33 am, Bryan Ford wrote:
> I’m glad to see the metadata-leakage protection topic drawing some
> interest, including some healthy skepticism on whether it’s practical. :)
>
> I’ll try to summarize my scheme at least somewhat concisely, and include
> this in a draft-of-a-draft that I have in progress.  [snip]
> Let’s work from a simple case to progressively more “interesting” and
> general cases:
>
> 1. Encryption using a single scheme (e.g., a single well-known
> “ciphersuite”) via a single passphrase.


Why is there a number for this....  Oh, because

> 2. Single symmetric-key scheme, but multiple alternative passphrases
> using that scheme.
> 3. Single public-key encryption scheme, with message encrypted for one
> or multiple public keys compatible with that scheme.
> 4. Multiple symmetric and/or public-key schemes, allowing multiple
> different passphrases and recipient public-keys each, respectively.


Ug :(

> —
> 1. Suppose simplistically we only want single-passphrase encryption
> using a single well-known encryption scheme.  More-or-less as usual for
> PGP, we (a) choose a random session key, (b) use a password-hashing
> scheme such as Argon2 to produce a symmetric encryption key that is used
> to AEAD-encrypt the file’s session key, and (c) use the session key to
> AEAD-encrypt the file’s content.  Assume for now that we encrypt the
> file in one big chunk, though chunking (with metadata encryption) can be
> added as well using existing techniques (e.g., those mentioned earlier
> analyzed in the context of SSH).


so far so good.


> 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.

  * 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).

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




> 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.

iang