[tahoe-dev] [tahoe-lafs] #217: DSA-based mutable files -- small URLs, fast file creation

James A. Donald jamesd at echeque.com
Thu Jan 7 04:09:35 UTC 2010


     --
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>





More information about the tahoe-dev mailing list