politics etc. (usual top-posting apology)
Thomas Lord
(31 Jan 2006 18:43 UTC)
|
Re: politics etc. (usual top-posting apology) Alex Shinn (01 Feb 2006 02:39 UTC)
|
Re: politics etc. (usual top-posting apology)
bear
(01 Feb 2006 03:34 UTC)
|
Re: politics etc. (usual top-posting apology)
Alex Shinn
(01 Feb 2006 03:57 UTC)
|
Re: politics etc. (usual top-posting apology)
Thomas Lord
(01 Feb 2006 05:44 UTC)
|
Re: politics etc. (usual top-posting apology)
Alex Shinn
(02 Feb 2006 03:01 UTC)
|
Re: politics etc. (usual top-posting apology) Alex Shinn 01 Feb 2006 02:39 UTC
On 2/1/06, Thomas Lord <xxxxxx@emf.net> wrote: > > In GNU Arch 1.x we have, I claim, decentralized + human-readable + > secure names. [...] > We again start with the idea of an infinite tree-topology > name-space in which ownership can be assigned (recursively) > to subtrees: > > community-sentiment > / | \ > top-level authorities This is an interesting compromise, but I wouldn't call it secure. As soon as you leave something up to "community sentiment," you've lost security, as there's nothing stopping people from creating their own, conflicting top-level authorities. Further the model itself doesn't guarantee that each top-level authority itself is secure. But perhaps we're thinking of different meanings of "secure" here. I'm claiming that to be secure there must be a unique mapping from name to entity, and this has to be _verifiable_ by automated means. In terms of Zooko's Triangle, the verification can either be decentralized (by making the name itself a signature), or human-readable, by establishing a trusted authority which can answer "who does this name belong to?" but you can't have both. By establishing a central authority to register each top-level authority, and standardizing protocols by which the authorities can verify names, you can get security. It's no longer decentralized, but the work is spread out over a tree of authorities. You could argue that you don't need secure names, but it's important not to lie to ourselves and claim something is secure when it isn't. Most people would be content with a naming convention that simply avoids unintentional conflicts. A secure naming system further resists malicious attacks. The hypothetical situation posted earlier was exploring what would happen if we tried to build a trusting, decentralized system of executing code, and signed and secured everything to the best of our abilities - with the exception that the module names themselves had no verification mechanism by their original design. The conclusion was of the sort of blinding obviousness that so often gets overlooked when such systems are designed - if you refer to external modules only by name, and those names themselves are not secure, then there is room for attack. The anecdotal doctor anecdote says "don't do that then." -- Alex