[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    Re: [Cryptography] IPFS spin locks !
From:       Henry Baker <hbaker1 () pipeline ! com>
Date:       2021-05-10 22:36:21
Message-ID: E1lgEXa-000DTI-Nj () elasmtp-galgo ! atl ! sa ! earthlink ! net
[Download RAW message or body]

At 03:13 PM 5/10/2021, Jerry Leichter wrote:
> > The IPFS (Interplanetary File System) *addresses* blocks
> > that are 'stored' within it by producing a *hash* of the
> > (immutable) block itself as its 'address'.
> > 
> > Assuming that the hashing algorithm is publicly known,
> > anyone can now create a spin lock whose 'address' is the
> > hash of some not-yet-stored-in-IPFS random file, and this
> > random file is communicated to other processes who all
> > need to synchronize with one another....
> 
> Heh.  This was (is?) a standard technique in the Linda programming model.  In \
> Linda, communication occurs through tuple space, where tuple space is the holder of \
> a multi-set of tuples of data of arbitrary types.  You can use out() to put a tuple \
> into tuple space; in() to atomically pull a "matching" one out in an atomic \
> operation; and rd() to atomically read the values in a "matching" tuple while \
> leaving it alone.  in() and rd() have arguments that are tuples of values or \
> wildcards; the values must match a tuple in tuple space while the wildcards get \
> filled in and are available to the caller.  in() and rd() - in the basic definition \
> of the model - are fully synchronous, waiting indefinitely for a tuple they can \
> match to appear.  So a lock is just a pre-defined tuple that those wanting the lock \
> can in().  Since the field types and values are arbitrary, this can be done \
> securely by choosing an appropriate value - though security was not something \
> really considered in the design of 
the model, which was intended for implementing cooperating components of a \
parallel/distributed program.
> 
> One nice thing about the basic model is the symmetry of communication:  Programs \
> can be written in which components doing out() have no idea who does in() or rd(), \
> and vice-versa.  Further, the order in which these occur doesn't matter:  If in() \
> occurs first, it simply waits for the corresponding out().  This avoids some common \
> problems with locks that occur when you don't carefully ensure that the lock is \
> actually there before someone tries to use it. 
> There are extensions to the model that allow timeouts, which (in my opinion) \
> greatly complicate the semantics and end up forcing you to design loops and \
> fallbacks which often end up hurting more than they apparently help.

Supposing IPFS used SHA256 for 'addresses/hashes'; the following
address:

852dba5b321a0eb4800e4e2099faa2353e85ae4f3b181e4e7b4ee1dd161e0482

when finally read, yields "Climb Mount Niitaka\n".

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
https://www.metzdowd.com/mailman/listinfo/cryptography


[prev in list] [next in list] [prev in thread] [next in thread]