James A. Donald wrote: > 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.
I was assuming a real-time stream, so the goal would be to provide a filecap before the source had finished generating all the bits. This would necessarily be a mutable filecap, unless you've got some way of predicting the future :-). If instead, you just have a large file that a client wants to fetch one piece at a time, well, Tahoe's immutable-file merkle trees already handle the goal of quickly validating a small part of a large byte sequence. You could use this in a non-real-time stream, in which you process the entire input stream, produce and publish the filecap, then a client fetches pieces of that stream at their own pace. > > 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? You're right, I was assuming a pre-existing secure "what to upgrade to" channel which could send down an integrity-enhanced download URL. To actually implement such a channel would require further integrity guarantees over mutable data. As I understand it, Firefox actually has a fairly complex upgrade path, because only certain combinations of from-version/to-version are fully tested by QA. Sometimes moving from e.g. 126.96.36.199 to 188.8.131.52 requires going through a 184.108.40.206->220.127.116.11->18.104.22.168->22.214.171.124->126.96.36.199 sort of path. The upgrade channel basically provides instructions to each older version, telling them which new version they should move to. The best sort of integrity guarantees I could think of would be a rule that says "the new version must be signed by my baked-in DSA key and have a version number that is greater than mine", or maybe just "the upgrade instructions must be signed by that DSA key". It's probably not a robust idea to make the rules too strict. cheers, -Brian --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com