[liberationtech] Espionge.app's lack of plausible deniability (Was: TrueCrypt Alternatives?)

[Greg]

Dear Steve,

Thanks for letting me know. Looks like only some of the sparsebundles are getting properly timestamped for some reason. We'll fix this for the next release.

You of all people, however, should know better [1] than to ignore my request that you disclose any security-related matters in a responsible way (by emailing us directly).

Although this isn't a serious bug, it's still a security-related issue and you don't know how failing to responsibly disclose it could affect someone.

Unbelievable.

- Greg

[1] http://saweis.net/ - "Stephen A. Weis Cryptography and Information Security"

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Oct 6, 2014, at 6:04 PM, Steve Weis <steveweis at gmail.com> wrote:

> To start with, the fake sparesebundle metadata and band modification
> times (i.e. the metadata's metadata) are distinguishable from a real
> sparsebundle's. Espionage's attempt to manipulate the metadata
> actually seems to be giving away which ones are fake.
> 
> Take a look at each sparesbundle's "bands" directory modification time
> as well as the distribution of individual bands' modification times:
> .../com.taoeffect.Espionage3/Data $ ls -R -l
> 
> In my case, I was immediately able to spot the real
> {UUID}.sparsebundle directory among many fake ones.
> 
> On Mon, Oct 6, 2014 at 1:52 PM, Greg <greg at kinostudios.com> wrote:
>> Dear Steve,
>> 
>> Espionage manipulates the filesystem metadata for sparsebundles, so it's
>> unclear to me whether you actually were able to distinguish them or not, but
>> if you were, please send an email to contact at taoeffect.com with your results
>> and we'll fix it!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20141006/13a0cbd8/attachment.html>