
<html><body style="font-family: Helvetica,Arial,sans-serif; font-size: 12px;">Okay, I'm sorry, let me rewind and explain a bit more. I forget that NDN and object-capability research don't overlap as much as I feel that they should.<br><br>So, what I'm asking for, precisely, is the ability to convert bytestrings (files) into *capability URIs*, which are URIs that are both sufficient and necessary for retrieving the file. This is tied to the notion of *capability* in OS and language design, where a capability, or "cap", is a communicable unforgeable token designating authority. In the case of NDN, the authority is to retrieve a file.<br><br>In Tahoe-LAFS, this is what a cap looks like: URI:CHK:h2bfkbufdlnuxxtf2b4qyyqt6y:jdrjht3qifq7hjv7l42woqtkxznapxn6xgtxd2v6xynslbsj3q4q:3:10:3221<br><br>If I pop that cap into a Tahoe-LAFS client connected to Matador Cloud's public Tahoe-LAFS grid, I get some SVG data back. What's in the URI, exactly? There's a flag that the content is immutable, a "storage index", which is an opaque name for the actual storage location in the cloud; a secret key which symmetrically encrypted the file, and three interesting numbers at the end: erasure coding parameters, as k-of-n, and the file size.<br><br>So, what's needed to make this work on NDN? Well, first, erasure coding is only interesting when you don't trust the network to be sufficiently durable to be able to keep your file alive. I feel that NDN solves this elegantly, and that as long as a file's live in somebody's Repo somewhere, there's not much risk of a file vanishing. So maybe we can leave that out. We can also leave out file size, and the storage index can be randomly-generated. NDN handles all of that just fine.<br><br>As for encryption, all that's really required is that the key and nonce are never reused and aren't deterministically generated by the file. (If they were deterministic, then an attacker could check to see if a certain encrypted data blob happens to be in a set of files that they have pre-encrypted deterministically. This attack won a Wall of Fame award from Tahoe-LAFS https://tahoe-lafs.org/hacktahoelafs/ )<br><br>So my idea is to randomly generate a key and nonce, make a libsodium box of the file, and put it into a Repo under a randomly-generated name. To share the cap, share the name, key, and nonce, perhaps as a tidy URI.<br><br>The NAC TR proposal can do things that I've not covered here, but doesn't actually directly talk about capabilities, so it's hard to compare apples-to-apples. I get the feeling that it's very complex, and that part of the complexity comes from allowing users to pick their own names for data.<br><br>My current design, then, is for users to have several instances of repo-ng or another Repo service running, geographically distrubuted. They sync to each other with ChronoSync. Their repositories are full of randomly-named opaque encrypted blobs. They use plain old NDN backbone (which I'll set up and own too) to share across the void.<br><br>Failure modes: Nothing short of leaking the cap or finding a flaw in the cryptographic construction should invalidate integrity and confidentiality at the data level. Users associate their uploads with their Repos, but their Repos can be given (non-user-picked!) codenames, so tying a person to an uploaded cap is as hard as asking the provider to turn over their account database. Mitigating the risk of account information being leaked...it's an open problem IMO. I want to not deploy accounts for precisely this reason, and instead craft accountcaps for managing accounts without having to turn over too much PII.<br><br>There's an alternative design where, instead of each uploader getting their own Repo, there's a global Repo. This is what the original Matador Tahoe-LAFS deployment does, with one single global non-accounted namespace. This works great for anonymity but not-so-great for the service provider getting paid, and I'm not sure how to fix that tradeoff.<br><br>Hopefully this fleshes out the security goals of my design.<br><br>~ C.<br><blockquote class="atmailquote"><br>----- Original Message -----<br><div id="origionalMessageFromField" style="width:100%;display:inline;background:rgb(228,228,228);"><div style="display:inline;font-weight:bold;">From:</div> "Lixia Zhang" <lixia@cs.ucla.edu></div><br><div id="origionalMessageToField" style="display:inline;font-weight:bold;">To:</div>"Corbin" <cds@corbinsimpson.com><br><div id="origionalMessageSentField" style="display:inline;font-weight:bold;">Cc:</div><ndn-interest@lists.cs.ucla.edu><br><div style="display:inline;font-weight:bold;">Sent:</div>Sun, 2 Jul 2017 12:59:15 -0700<br><div id="origionalMessageSubjectField" style="display:inline;font-weight:bold;">Subject:</div>Re: [Ndn-interest] repo-ng and least-authority storage<br><br><br><br>

> On Jun 27, 2017, at 8:32 PM, Corbin <cds@corbinsimpson.com> wrote:<br>

> <br>

> Oh, I forgot redundancy! Let's say that I want to run three repos in different availability zones; can I have them all synchronize with each other somehow?<br>

> <br>

> Peace,<br>

> ~ C.<br><br>

looks like no one has responded yet, so let me throw in a stone in a hope to attract jade ;-)<br>

from your msgs it's not exactly clear what are the security goals you want to achieve.<br><br>

for your 2 specific questions:<br>

1/ one does not need to trust storage servers; the NAC TR specifically discussed this issue and suggested a solution<br>

https://named-data.net/wp-content/uploads/2016/02/ndn-0034-2-nac.pdf<br><br>

2/ one can sync up distributed repos using an NDN sync protocol. <br>

several exist, ChronoSync got used most.<br><br>

> ------ Original message------<br>

> From: Corbin<br>

> Date: Tue, Jun 27, 2017 19:37<br>

> To: ndn-interest@lists.cs.ucla.edu;<br>

> Cc:<br>

> Subject:[Ndn-interest] repo-ng and least-authority storage<br>

> <br>

> Hi,<br>

> <br>

> I want to know if the following security design is provider-independent; that is, whether it still holds even if I don't trust the NDN nodes running repo-ng.<br>

> <br>

> To make a cap for a file, generate a secret key and nonce, use libsodium to put the file in a box with the key and nonce, and finally, insert the box in a repo with a random name. The name, key, and nonce form a capability for the file; the capability is necessary and sufficient for file retrieval.<br>

> <br>

> This is a lot less work than Tahoe-LAFS has to put in! Would it really work?<br>

> <br>

> Peace,<br>

> ~ C.<br>

> _______________________________________________<br>

> Ndn-interest mailing list<br>

> Ndn-interest@lists.cs.ucla.edu<br>

> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br></blockquote></body></html>