On Sun, Jul 15, 2012 at 6:15 PM, David Barrett <[email protected]>wrote:
> $ apt-get install cryptosphere > $ cryptosphere put <filename> > Success, stored as: <encryptedSHA> <publicSHA> > $ cryptosphere get <encryptedSHA> <publicSHA> > Success, saved to: <filename> > Something like that, although I'd prefer to have human-meaningful aliases around the capability tokens, rather than requiring users to interact with them directly. While I'll be using ECDSA, I have not taken many of the steps in Tahoe used to reduce the length of the capability tokens. > I agree with that goal, but I'd argue that usability trumps that: I'd > rather have a less-secure system that people use, than a more-secure > system that people don't use. Again, I don't know the usability > tradeoff that the encryption causes: ideally it'd be so under the hood > (like Skype) that you wouldn't even know it's happening. My goal is for the crypto to be completely transparent to the end user. > But if my above guess about the CLI syntax is right, then it means > everybody who > stores a file into the system must hold on to not one, but *two* > extremely long hex numbers in order to fetch the file. This feels > unwieldly. Or is this all off? Human-meaningful aliases for those hex numbers get rid of the paoin point here. -- Tony Arcieri
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
