[tahoe-dev] Bringing Tahoe ideas to HTTP

James A. Donald jamesd at echeque.com
Sat Sep 5 02:14:46 EDT 2009

Nicolas Williams wrote:
 > > One possible problem: streaming [real-time] content.

Brian Warner wrote:
 > Yeah, that's a very different problem space. You need
 > the low-alacrity stuff from Tahoe, but also you don't
 > generally know the full contents in advance. So you're
 > talking about a mutable stream rather than an
 > immutable file.

Not mutable, just incomplete.

Immutable streaming content needs a tiger hash or a
patricia hash, which can handle the fact that some of
the stream will be lost in transmission, and that one
needs to validate the small part of the stream that one
has already received rather than waiting for the end.

 > upgrade bundles are produced by a very strict process,
 > and are rigidly immutable [...] For software upgrades,
 > it would reduce the attack surface significantly.

But how does one know which immutable file is the one
that has been blessed by proper authority?  Although
Version 3.5.0 is immutable, what makes it Version 3.5.0,
rather than haxx350, is that some authority says so -
the same authority that said that your current version
is 3.4.7 - and it should not even be possible to get a
file named by some different authority as an upgrade.

Of course, one would like a protocol that committed the
authority to say the same thing for everyone, and the
same thing for all time, saying new things in future,
but never being able to retroactively adjust past things
it has said.

In other words, upgrades should be rooted in an append
only capability.

I suppose this could be implemented as a signed dag of
hashes, in which whenever one upgraded, one checked that
the signed dag that validates the upgrade is consistent
with the signed dag that validated the current version.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

More information about the cryptography mailing list