-- tahoe-lafs wrote: > #217: DSA-based mutable files -- small URLs, fast file creation > ------------------------------------+--------------------------------------- > Reporter: zooko | Owner: zooko > Type: enhancement | Status: assigned > Priority: major | Milestone: eventually > Component: code-mutable | Version: 0.7.0 > Keywords: mutable crypto newcaps | Launchpad_bug: > ------------------------------------+--------------------------------------- > > Comment(by zooko): > > Argh! I just encountered a new example of how the > current Tahoe-LAFS caps are too long to be acceptable > to most users. > > I had commented on the blog of (good security > researcher) Nate Lawson -- > http://rdist.root.org/2009/12/30/side-channel-attacks > -on-cryptographic- software/ -- and included a link > to my klog, namely this link:
> > http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html > > He edited my comment and replaced that link with this: > > http://allmydata.org/pipermail/tahoe-dev/2010-January/003476.html The link in its full horror was visible in the comment, that is the bug, not the length of the link. Globally unique identifiers are for computers, not humans, hence should not ordinarily be exposed to humans. If exposed, they are always too long and can never be made sufficiently short. The bug is that the link is <p>Here is what I think: thanks for writing this! It spurred me to reconsider this issue that has been bothering me, and I came up with a new (to me) solution for my decentralized filesystem: combine a timing-attack-resistant cipher like XSalsa20 with AES and make sure that AES doesn’t get to see your master key or your plaintext:</p> <p><a ref="http://allmydata.org/pipermail/tahoe-dev/2010-January/003476.html" rel="nofollow"> http://allmydata.org/pipermail/tahoe-dev/2010-January/003476.html</a></p> When it should be <p>Here is what I think: thanks for writing this! It spurred me to reconsider this issue that has been bothering me, and I came up with <a href= "http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html" rel="nofollow">a new (to me) solution</a> for my decentralized filesystem: combine a timing-attack-resistant cipher like XSalsa20 with AES and make sure that AES doesn’t get to see your master key or your plaintext:</p> _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
