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] Secure Cloud Computing: Virtualizing the FreedomBox

Caspar Bowden (lists) lists at casparbowden.net
Thu Apr 24 11:13:18 PDT 2014


On 24/04/14 19:21, Zooko Wilcox-OHearn wrote:
> On Tue, Apr 22, 2014 at 11:47 AM, Caspar Bowden (lists)
> <lists at casparbowden.net> wrote:
>> TAHOE is also cool, but doesn't claim to provide confidentiality. A TAHOE
>> service provider would have no choice but to round-up/backdoor the necessary
>> keys under existing US (FISA/PATRIOT) or UK (RIPA Pt.3) legislation [or
>> Indian IT Acts etc. etc.]
> Oh, by the way, this part was incorrect. An example of a Tahoe-LAFS
> service provider is my company, https://LeastAuthority.com.
> LeastAuthority.com does not have any ability to acquire our
> customers's keys, nor to backdoor our customers.

This is semantics. If you provide the service to a customer, you can be 
forced to backdoor <http://www.wired.com/2007/11/hushmail-to-war/> 
(let's define terms "Customer", "Provider", "user", "individual  data 
subject" if want to continue, else will get ourselves hopelessly 
confused - or if you point me at the part of the spec you think 
invulnerable will show you how FISA or RIP can round-up keys)

It's in FISA 702 expressly, and as we now know, key disclosure can even 
be forced under S.215. Not saying this to knock TAHOE, but often in 
Cloud discussions, people are looking at a conventional threat model - 
protecting against external attack and insider *un*authorized access. 
But the new part of the threat model, relevant post-Snowden, is 
authorized insider access lawfully required by the jurisdiction to which 
that Cloud is exposed.

The UK law RIPA Pt.3 (2000) was even written with extreme (and correct) 
detail to give powers to round up arbitrary number of key fragments 
(whether this might be defeated by lots and lots of fragments is debatable)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20140424/16c3739d/attachment.html>


More information about the liberationtech mailing list