Login

Redecentralize

We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.

Home

Parent
Nicholas H.Tollervey [LibreList] Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches 2014-08-15 17:46:37 (6 years 7 mons 18 days 15:30:00 ago)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 07/08/14 10:31, Jörg F. Wittenberger wrote:
> Am 06.08.2014 13:58, schrieb Nicholas H.Tollervey:
>> 
>> Items stored in the drogulus are designed to stand on their own
>> and be self-verifiable through cryptographic signing.
> 
> Thanks for your feedback.
> 
> I see quite some interesting things in Drogulus.
> 
> However I'm "sort of" skeptic when I read "crypto signing".  This
> term is too generic and too often implies secret key crypto.
> However an important part of a signature is in these schemes hidden
> in the process: as a proof of integrity, we are interested in a
> hash over the object's content.  This proof should hold even if the
> secret key was lost or published.
> 

The drogulus uses public key cryptography (RSA) for signing digital
assets.

>> 
>> An item stored in the DHT is a collection of named fields and
>> associated values (it's a JSON object):
>> 
>> * value - the actual value to store. * timestamp - a UNIX
>> timestamp representing when the creator of the item thinks the
>> item was created (so it's easy to work out the latest version of
>> an item given two candidates). * expires - a UNIX timestamp
>> beyond which the creator of the item would like the item to
>> expire, be ignored and deleted in remote nodes. * name - a
>> meaningful name given by the creator for the key. * created_with
>> - the version of the drogulus the creator used to generate the
>> item. * public_key - the creator's public key. * key - the
>> SHA-512 value of the compound key (based upon the public_key and
>> name fields) used as the actual key on the distributed hash
>> table. * signature - a cryptographic signature generated using
>> the creator's private key with the fields described above.
> 
> When it comes to contracts, one might find it a good idea to define
> a slightly higher level hash function: extract (or attach) relevant
>  information to assert provenance: creator, witness, time etc. and
> hash these together with the hash of the actual value.
> 

So the creator (via their public key) and time of creation are all
constituent in creating the hash.

> Now if you take this hash as canonical identifier for the object,
> you can always proof it's integrity.  See also: 
> http://www.iang.org/papers/ricardian_contract.html for yet another
> explanation of the same concept.
> 

Yes, that is correct.

> Question: Am I correct to understand that the "key" field serves
> this purpose?
> 

It is, indeed a unique identifier for the item.

> I'm a bit concerned about the inclusion of some public_key here.
> This identifier should IMHO only cover non-repudiable, public (or 
> semi-public) meta data.  No private data an nothing one would ever
> want to change.
> 

I'm not sure I understand you completely. The public key is required
in order for third parties to validate the signature (created with the
associated private key).

>> The public_key field is used to validate the signature value. If
>> this is OK then the compound SHA-512 key is checked using the
>> obviously valid public_key and name fields.
>> 
>> This ensures both the provenance of the data and that it hasn't
>> been tampered with. Any items that don't pass the cryptographic
>> checks are ignored and nodes that propagate them are punished by
>> being blocked. It also confirms that the generated SHA-512 key
>> for the item is correct given the public_key and meaningful name
>> ensuring no other entity may set items with this unique key
>> (assuming no key collision vulnerability in the hashing
>> function).
>> 
>> Does this make sense..?
> 
> Yes, quite a lot.
> 
>> Happy to answer questions and please remember, this is more an 
>> experiment in code.
> 
> I fully understand that.  See: in about 2000 I started coding
> around similar ideas.  As the system majored, we ran into various
> additional ideas.  Maybe some are interesting or inspiration:
> 
> Once we have the DHT, what do we do with it?  I'd like it to handle
> my conversation and business.  Publications, private messages, 
> archive+backup, calendar, notes etc.
> 

Quite... the drogulus is supposed to be application agnostic.

> So I need an environment where I see agents (be them accounts 
> representing human users or automated, autonomous processes) 
> communicating via asynchronous, unreliable, unidirectional
> messages. That's how we observe human interaction in writing.
> Humans or juristic persons sending letters, registered mail etc.
> 

Again, quite. Actually, it's not just humans - I've been reading quite
a bit of literature on insect interactions, communication and
behaviour. A good overview and a book I particularly enjoyed was
Deborah Gordon's "Ant Encounters - Interaction Networks and Colony
Behaviour".

> Side note: Tuns out documents like contracts (which is what
> "business" boils down into) could seen as a finalized subclass of
> agents which just don't change state ever.  However in practice a
> fuse mounted directory at my desktop is just yet another such
> agent, certainly changing state.
> 

Hah... a trivial distributed "Dropbox" clone built with fuse is one of
my target "quick example" applications (a la "create a blog" for web
frameworks and "create a todo list" for Javascript frameworks).

OK... I'm going to call a time-out. I've read the following but won't
comment simply because I'm about to leave to spend some time on a
remote Scottish island without internet (but I wanted to reply before
I left the relatively connected location of the mainland - I'm playing
email catch-up).

I'll re-read what follows (which upon first reading is very
interesting) and reply in full when I'm back on dry land in about a
week's time. Many apologies, but I'm a sufferer of the intractable
too-much-to-do-and-not-enough-time-to-do-it-in problem.

:-/

N.

> Next I need a dispute (or debug) mode.  This must be deadly simple:
>  "pull the network plug".
> 
> At this point I still want to be sure I have all *my* data and can
>  access it.  (Sorry for the complication wrt. DHT design.  ;-)
> 
> Now we know that I have one copy of all data I *really* care about
> which I can physically secure.
> 
> At this point we can ask how we may update automated agents.
> Sometimes they might just have a single owner, but often control is
> to be purposefully split.  At this point the GET/PUT semantics are
> no longer enough.  We need some kind of custom, version control
> alike check in script to be run to verify that the request is
> permitted and complete for this object. It looks like a good idea
> to have a type property in the agent object pointing to another
> (signed) object which holds the script code and important: human
> readable terms and conditions.  The other object would be the
> contract governing the agents actions on incoming requests.  No
> script object found: either no updates or locate script in the
> object itself.
> 
> Now we need "trust but verify": since we must not allow any single
> human to control the agent, we can not allow a single computer to
> compute the update and then somehow copy the new state to other
> peers.  After all the origin peer might be a traitor.  We need
> autonomy from individual intent for these agents.  Therefore we
> have several peers (notaries) commissioned to backup the process
> and verify proposed updates.  Instead of blindingly accept any kind
> of update, those accept an update request and transform it into the
> actual update (or the script may reject the update for application
> defined reasons. So the script is run in a sandbox at each
> notary.)
> 
> Let's care for a moment about privacy.  Crypto always has a chance
> to break for many reasons.  And crypto is in the way of autonomous
>  automated agents and often in the way to the user too.  Crypto
> relying on secret keys is great on the wire for data in transit.
> For data at rest, it's a risk increasing over time.  Instead we
> ask: which peers do we commission to such an agent?  This set
> should really be controlled by the users.  (I.e., the update policy
> script *must* be able to deny changes.)  This is a trust decision
> wrt. the person administrating the peer and the peer hardware and
> maybe more.  Nothing technological means can judge; it's a judgment
> about those very means among more.  Ergo: publications and messages
> may leave the commissioned set, private data will never.
> 
> Eventually I wonder how much effort it would be to maintain those
> expire times.  I don't want to do that manually.  Maybe there could
> be an automated garbage collector?  Establish a link structure from
> your user account and everything not reachable from any local user
> may be removed on this peer.
> 
> For the script language: it should be first and foremost a
> "hashbang" type of a language: simple and often only used to start
> the real interpreter for the contract script at hand.  However
> there is nothing bad about having a powerful language to be started
> that way.  We had about ten developers of varying experience (from
> bachelors to full time contracted CS masters) in a working
> environment with close feedback test and develop atop of our
> prototype for several years while we where working on the
> underlying replication engine and feature.  Too many features that
> is, see "fuse" before.  In this time we grew quite a flexible
> language BAIL: a mixture of XSLT, a python-style syntax (a.k.a. 
> "sweet syntax"), a pure functional Scheme subset and SQLite.  Very
> funny to work with, because each object has it's private table
> space - zero DB administration.  However this language is certainly
> not the point. The CoreAPI to control the DHT entries is much more.
> It's only seven required elements ad eight more to make it
> practical. http://askemos.org/index.html?_v=search&_id=1728 (the
> documentation is a little terse ;-)
> 
> Do those ideas make sense to you?
> 
> Best
> 
> /Jörg
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJT7jltAAoJEP0qBPaYQbb6jBQIAKeQokUP+dICTeW2iIp8w7T/
y+FC5/KGAJeUHm12QI6GIgbqn8yky676RZUWuSv4HQo0nf+jhr/+ogwx3dJnYzBB
MV/kAqGqfU9/JT8jvVNtrBrpCP3CDkR0VhhpcRQuhNV2ZCPl1jsZJl3r3/XuubKu
KihT0nEpgHeqH32kq4ZoYG4TqMMLT0QUuxW3nvm6b1Qwv/DdTqstlfldxQrGIchh
Ld5AOv88LjfuqEQt3gew+hv+oNe1n4UUXkDEzF89DuNLIOpbjhlbpzAZfZLswYWO
Jv5KPTe17fuBR+eqINEcbfZEWyg/yJGnRp5EshYV04+oOdAVq/VRyrqz56VbcXs=
=pYRE
-----END PGP SIGNATURE-----
: