[Cryptography] propaganda on "hurdles for law enforcement"

[Peter Fairbrother]

On 25/07/14 22:24, John Denker wrote:

> Also note that if such a defense is not possible, you are already
> a criminal, because of the encrypted "message" below, which you
> have already received.
>   a) You don't know the decryption key, although nobody can prove
>    that you don't.
>   b) You cannot obtain the key from me or anyone else, because
>    I destroyed the public key /before/ encrypting the message,
>    although nobody can prove that I did.
>   c) Furthermore I can tell you that the plaintext consisted of
>    512 bytes of high-grade randomness that wasn't seen or recorded,
>    although nobody can prove that either.
>
> I encourage you to forward my "message" to all your legislators,
> along with lots of similar messages.
>
> To say the same thing in more constructive terms: This serves
> as an example of /cover traffic/.


There is a another, different hypothesis - that the lump of data is the 
same lump of data, possibly re-encrypted, as another lump of data 
somewhere else.

Perhaps we need a new definition of (pseudo-) random for that situation.




On a personal note, I have been struggling with this idea, in terms of 
cover traffic, for the last 9 or 10 years - but I haven't gotten 
anywhere much beyond the obvious, nothing noticeably brilliant :(

IMO. the whole subject of cover traffic needs to be investigated much 
further, and with rigor.





Take, as an example, a steganographic filing system where the files are 
kept in a public cloud, and it is easy for an observer to see when 
encrypted files are stored and recovered.

For simplicity, assume all files are the same size (padding, 
concatenation of associated files, etc).

In the cloud there will be real files which contain real data, and cover 
files which do not. The files, real or cover, may be re-encrypted from 
time to time, and perhaps returned to the cloud under different 
identifiers.

To an observer the operation of re-encryption should be the 
indistinguishable from the operations of writing, modifying, or deleting 
[1] a file.

In one instance of this there are multiple copies of real files and 
cover traffic files, so that an observer who can see traffic cannot 
imediately identify which files are real and which are not. The user may 
also keep a local pool of files to make real-world timimg information 
less useful.



The problem now is the pattern of file accesses. If the user loads ten 
files every time he starts a session, it is much harder to hide the real 
files than if he does not.

Ideally, file accesses should look random - but this is not practicable, 
and if we don't want the user to have to wait days to open a file, it is 
perhaps not even possible.



Now comes the only smart part I have found:


Somewhat easier ( or perhaps a _lot_ harder ) than generating lots and 
lots of random traffic, the covertraffic generator might generate lesser 
amountys of *suspicious but bogus* patterns of file accesses.


That can perhaps lessen bandwidth, but it ain't easy.






[1] though the encrypted file will always, always be available ...


-- Peter Fairbrother


 > allows you to say with
> complete sincerity that at least "some" of the data you hold
> is undecryptable.
>
>     Adversaries will have to consider the hypothesis that I'm
>     engaging in some bizarre yet effective steganography, hiding
>     a tree in the front row of the forest.  Nobody can prove /or/
>     disprove this hypothesis.