[liberationtech] Have any of you ever used Scuttlebot?

[Daniel Bosk]

It would probably be better to adapt a signature scheme for JSON. 
Something along the lines of a hash tree (Merkle tree). Hash the leaves 
(key and value together), then *sort the hashes*, hash them together. 
And continue like that up to the root. Finally, the hash of the root is 
signed.

It's not what JSON would serialize to in text (with spaces and newlines) 
that's interesting to sign, it's the values. The keys and values remain 
the same no matter how you serialize it.

        Daniel

On Wed 22 Apr 2020 05:10:20 GMT, fuzzyTew wrote:
> It sounds like an implementation of the secure scuttlebutt protocol
> requires a json parser that preserves ordering of object keys in both
> directions.
> 
> On Tue, Apr 21, 2020, 2:44 PM John Ohno <john.ohno at gmail.com> wrote:
> 
> > Sorting the keys is absolutely a component of the solution, but doing so
> > makes the format functionally not standard JSON, & also means that code
> > needs to be injected into third party JSON libraries. JSON, as specified,
> > does not define key order, which makes any variation of JSON that cares
> > about, exposes, or allows you to control key order not really JSON.
> > Libraries aren't required to expose this, & so to the extent that they do
> > (ex., the JSONSimple library in java) it's a side effect of an abstraction
> > leak (like preserving insertion order) & can't be relied upon not to change
> > in some future release -- which adds maintenance headaches, since a change
> > in a third party library can break your implementation.
> >
> > On Tue, Apr 21, 2020 at 11:49 AM Steve Phillips <
> > steve at tryingtobeawesome.com> wrote:
> >
> >> > Fully independent implementations are under development, but they're
> >> difficult because the protocol as defined involves cryptographically
> >> signing sections of regular JSON -- which, of course, has no defined order
> >> for objects. This means that in practice, the SSB protocol is not standard
> >> JSON plus signatures, but the entire set of nodejs JSON serialization
> >> quirks.
> >>
> >> SSB doesn't sort the keys first to ensure the JSON serialization is
> >> simple and deterministic?
> >>
> >> --Steve
> >>
> >>
> >> On Mon, Apr 20, 2020 at 9:40 PM John Ohno <john.ohno at gmail.com> wrote:
> >>
> >>> I have used scuttlebutt for a few years. Unfortunately, in the past
> >>> month or two, I've found the clients a lot less reliable, so I haven't been
> >>> on very much.
> >>>
> >>> SSB has an interesting culture. The developers are very concerned with
> >>> the social ramifications of offline-first & truly-peer-to-peer
> >>> communication, and are seriously discussing (and making technical decisions
> >>> about) the kinds of media theory issues that get only idly discussed on the
> >>> fediverse (and almost not at all in centralized social networks). For
> >>> instance, SSB functionally has transitive blocking, & this lowers the
> >>> moderation load on individuals, who are simply inaccessible if the number
> >>> of hops between connections is too high.
> >>>
> >>> I don't know how good SSB's *privacy* features are. From what I can
> >>> tell, they aren't very concerned with that, as compared to
> >>> anti-falsification (which is functionally just necessarily for good p2p in
> >>> an offline-first setting). There are private message systems, but I haven't
> >>> used them (let alone security-audited them).
> >>>
> >>> Fully independent implementations are under development, but they're
> >>> difficult because the protocol as defined involves cryptographically
> >>> signing sections of regular JSON -- which, of course, has no defined order
> >>> for objects. This means that in practice, the SSB protocol is not standard
> >>> JSON plus signatures, but the entire set of nodejs JSON serialization
> >>> quirks. In order to implement it in another language, you have to duplicate
> >>> exactly the ordering produced by nodejs, or else old messages will not be
> >>> interpreted as valid by your implementation and the messages produced by
> >>> your implementation will not be interpreted as valid by competing
> >>> implementations. Ultimately, this means that if you want a full-featured
> >>> SSB client, you're stuck with an electron app (with all the attendant bloat
> >>> and memory leaks).
> >>>
> >>> On Mon, Apr 20, 2020 at 2:52 AM Daniel Bosk <dbosk at kth.se> wrote:
> >>>
> >>>> No:
> >>>>
> >>>>   https://ieeexplore.ieee.org/abstract/document/6197506
> >>>>
> >>>> One must design it carefully. But if done right, it's really nice.
> >>>>
> >>>>         Daniel
> >>>>
> >>>> On Sun 19 Apr 2020 01:24:02 GMT, Yosem Companys wrote:
> >>>> > P.S. Is P2P inherently more or less secure than the alternative?
> >>>> --
> >>>> Liberationtech is public & archives are searchable from any major
> >>>> commercial search engine. Violations of list guidelines will get you
> >>>> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
> >>>> change to digest mode, or change password by emailing
> >>>> lt-owner at lists.liberationtech.org.
> >>>
> >>> --
> >>> Liberationtech is public & archives are searchable from any major
> >>> commercial search engine. Violations of list guidelines will get you
> >>> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
> >>> change to digest mode, or change password by emailing
> >>> lt-owner at lists.liberationtech.org.
> >>
> >> --
> > Liberationtech is public & archives are searchable from any major
> > commercial search engine. Violations of list guidelines will get you
> > moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
> > change to digest mode, or change password by emailing
> > lt-owner at lists.liberationtech.org.

> -- 
> Liberationtech is public & archives are searchable from any major commercial search engine. Violations of list guidelines will get you moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe, change to digest mode, or change password by emailing lt-owner at lists.liberationtech.org.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ghserv.net/pipermail/lt/attachments/20200422/1755618c/attachment-0001.sig>