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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp