ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Reducing the meta-data leak

2015-11-09 10:16:53
Thanks Ian for the feedback! (and the patience :) )

On Nov 8, 2015, at 1:02 PM, ianG <iang(_at_)iang(_dot_)org> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
<Prev in Thread] Current Thread [Next in Thread>