Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

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

Greg greg at kinostudios.com
Tue Oct 7 16:29:54 PDT 2014


On Oct 7, 2014, at 11:31 AM, Collin Anderson <collin at averysmallbird.com> wrote:
> For that matter there is still language such as "virtually impossible" on your site  [1], which appears increasingly like a departure from how Espionage works in its current state. In fact many privacy tools in the FOSS and other communities go as far as to caution users where their products don't work. I think you should strongly consider that by the way.

Thanks so much Collin! It's been fixed on the site.

I've kept the words "virtually impossible" but have rephrased the original sentence to make what was being stated clearer and more accurate.

I also added a giant disclaimer in bold yellow font below it as per your second recommendation, and I sent out a tweet from @espionageapp to notify our users of the change:

https://twitter.com/espionageapp/status/519627827503583233

Here's what it says now:

Fake disk images and fake Folder Sets have the potential to make it virtually impossible to tell whether a user has shown you all of their encrypted data. The fake data looks just like the real data, and we’ve even taken pains to ensure that all of the files inside of the fake disk images have random (and convincing) timestamps on them.

Update October 7, 2014: However, as of this release, the timestamps on the fake disk images are not sufficient to fool all infosec professionals. We are researching methods that will fool infosec researchers while still being respectful of our user’s backup systems (like Apple’s Time Machine, SpiderOak, etc.). Users might end up having to choose between super-convincing deniability and having to backup fake data periodically. We thank Steve Weis, Collin Anderson, and the [LiberationTech] community for pointing out that we should have made this clear here, and apologize for not having done so originally.


I will devote some time tonight to comb through our posts on the topic and see if I can find any other places where the wording could be improved or where a disclaimer needs to be added.


> I would argue that you maintain a responsibility to uphold those commitments.


Yes, I feel the same way about it.

Thanks again! If you or anyone else finds something I missed please do bring it to my attention and it will be fixed ASAP! :-)

Kind regards,
Greg Slepak

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


> 
> On Tue, Oct 7, 2014 at 1:25 PM, Greg <greg at kinostudios.com> wrote:
> If you want me to open a CVE, I need to hear from you (and anyone else advocating that I go through the process of opening and maintaining CVE after CVE about the always imperfect PD we provide) why we should be required to open a CVE when TrueCrypt, which provides _worse_ PD is not asked to open and maintain CVEs for their (to-date-perpetually-worse) PD.
> 
> The baseline of security disclosures that you offer to your clients should not be determined by the failures of others. People have always felt uncomfortable about TrueCrypt for reasons such as these, and if you want to build greater trust with communities such as Libtech then you should learn from others' mistakes. I cannot tell you how you should interact with clients, but I can say that you have sold your product based on certain claims historical. Regardless of whether these claims were removed, I would argue that you maintain a responsibility to uphold those commitments. For that matter there is still language such as "virtually impossible" on your site  [1], which appears increasingly like a departure from how Espionage works in its current state. In fact many privacy tools in the FOSS and other communities go as far as to caution users where their products don't work. I think you should strongly consider that by the way.
> 
> I respect that you feel the need to be defensive right now, and appreciate that you haven't just abandoned the thread, but if there is unfair criticism of your product it still is not constructive to tell people to 'shut the fuck up.' Honestly, I don't care if you file a CVE or not, but please never use the human rights activist claim again.
> 
> [1] https://www.taoeffect.com/blog/2014/07/major-advancements-in-deniable-encryption-arrive-in-espionage-3-6/
> 
> --
> Collin David Anderson
> averysmallbird.com | @cda | Washington, D.C.
> --
> Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20141007/6a99e963/attachment.html>


More information about the liberationtech mailing list