[Cryptography] Really good ideas, harsh reality, tailored covertraffic
Peter Fairbrother
peter at tsto.co.uk
Sun Aug 30 00:03:08 EDT 2020
I don't know whether you have been following the terakey thread, but
afaict it is something which at first sight looks like a great idea, but
turns out not to work as advertised.
I had a similar - looks great but doesn't work - idea a decade or more
years ago, in the context of steganographic file systems "in the cloud";
or more generally steganographic file systems where every read and write
is visible to an attacker.
[a steganographic file system is a file system where unless you know the
relevant keys you can't tell whether something in it is a real file or
not, nevermind read the contents]
[this is not a cautionary tale, but it did hurt at the time]
The cloud filing system would have a bunch of files, all the same size,
all filled with random-looking data, stored in the cloud. Some of these
would contain encrypted real user files, some would just be actual
random data.
A subset of these files would also be copied/stored in the user's
computer. They would act as a pool.
Using universal re-encryption these pool entries would be re-encrypted
and returned to storage in a randomly-chosen fashion, replacing their
cloud counterparts, at regular intervals - the mechanism to do this
would not need to know whether the file was a real file or not [1].
Another file, chosen either at random or in accordance with user read
need, would then be transferred into the pool replacing the written-out
file in the pool.
This store-fetch cycle would repeat at regular intervals.
When a real user file was created or deleted it would initially go into
the local pool; in the creation case replacing a randomly-selected pool
entry, in the deletion case by deleting the user key.
As the cycle mechanism would not know whether the local pool file was a
real file or not (if it did know it could be called to account), real
files were duplicated and spread over the cloud to minimise deletion.
Bit complicated, but that part also worked.
Great idea. The paper was accepted for one of the PET conferences. Many
people congratulated me.
Except - it doesn't work in real-world numbers. There are patterns to
real user file accesses, and these patterns are detectable.
If an attacker can see all present and past reads/writes to the cloud
store, using that randomly-chosen replacement pool system you can only
say a vanishing proportion of the real files are secure in existence.
Practically it might be useful, but only against your little sister.
Well maybe a bit, or quite a bit, more than that; but not securely,
against a major adversary.
So I went away and gnawed my liver.
Damn. Great-seeming idea, but it didn't work. BTW, after a while fresh
human liver makes you feel sick and have the dire-rear.
But ..
Out of this chaos I invented tailored covertraffic.
Tailored covertraffic is covertraffic where an observer can't say with
any certainty, based on all past observations and all other link-based
evidence available to him, that any piece of traffic is real traffic -
as it could also have been plausibly generated by the tailored
covertraffic generating mechanism.
Tailored covertraffic covers real traffic better than random
covertraffic because it can cover a specific piece of real traffic more
efficiently than random covertraffic can by hiding it in a
smaller-but-more-likely set of possible traffics.
I have often meant to write a paper about tailored covertraffic,
someday: but it is not complicated, just complex, the name and
description should be enough to give the idea.
There is still one more problem (at least) - given a cloud storage set
and a set of revealed files, can an attacker say with confidence that
there are more real files still to be revealed (without identifying
which files) in the storage set?
And all this with a complete historical access/change history?
Afaict neither is an insoluble problem, but they do have to be considered.
And I also invented - but that's another story, I'm working on that. :)
Peter Fairbrother
[1] I also invented a suitable universal re-encryption mechanism for this.
and this has now a become an almost drunken rambling, so don't take it
too otherwise. But it may still be a bit wise, I hope, else I wouldn't
have posted it.
More information about the cryptography
mailing list