Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scuttlebot: Peer-to-peer database, identity provider, and messaging system

scuttlebot.io

Post reply on HN
Print view View original

91–100 of 123 posts

Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system

#91

Post by aabbcc1241 »

rakoo wrote: post #88
sneak wrote: post #43

Earlier quoted context omitted.

When I was faced with this (signing a structure), I serialized the json into base64, then put that base64 string as a value (along with the MAC) into a new json document. It of course increases deserialization overhead (json, verify, unbase64, inner json) but sidesteps this issue. I thought about sorting keys and other things like that, and the dozen edge cases and potential malleability issues dissuaded me for the c…

Use Bencoding, like bittorrent does: https://en.wikipedia.org/wiki/Bencode As I put in another comment, a torrent id is a hash of a map, where one of the keys contains binary data. bencoding solved that decades ago already.

It looks similar to stackish and BON (binary object notation) https://github.com/bon-org/bon-doc/blob/master/README.asciid...

BON is compatible with json+ and erlang data type, in specific, it allows any data type for the map key. Json only allows string as map key.

Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system

#93

Post by Aeolun »

crispyporkbites wrote: post #63
camdenlock wrote: post #26

Earlier quoted context omitted.

Yeah, this is where I lost interest too.

I don’t understand why npm install is so bad here? It’s just a package manager. It’s not hard to write your implementation without npm if you prefer.

I think npm is barely a package manager.

Yarn is a bit better, but it’s also my experience with most of the stuff in the JS ecosystem.

Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system

#94

Post by myself248 »

miguelmota wrote: post #42

Here's a getting started with scuttlebutt tutorial I wrote last year for beginners https://miguelmota.com/blog/getting-started-with-secure-scut...

There's an unstated assumption in all these things, that you already know some people in the network. If not, you can see all sorts of interesting things, but nobody knows you're replying to them, and it's a very lonely experience.

If there's a way around that, I haven't figured it out, and all these tutorials aimed at people who've never heard of the network seem misplaced -- if you don't already have a personal invite, the network is useless to you, but if you already have a personal invite, the article is useless to you.

Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system

#96

Post by ben509 »

dboreham wrote: post #52
Vendan wrote: post #31

Scuttlebutt is a neat concept, burdened by a bad protocol. Signing a message involves serializing a json object, signing it, adding the signature as a field on that json object, and then serializing it again. To verify, you deserialize the message into an object, remove the signature field, and then reserialize it, and verify the signature against that new serialization. This means that all the clients have to have a…

Any signing done over structured data has this problem. You always need a canonical representation.

It would be simpler to work out a canonical reduction for JSON. This should be reasonably easy since there are so few elements to it.

A simple proposal for actual security guys to rip to shreds:

Strings are represented as utf-8 blobs, and hashed.

Numbers should probably be represented using a proper decimal format and then hashed. If you're reading the JSON in and converting it to floats, you could get slight disagreement in some cases.

Arrays are a list of hashes, which itself is hashed.

For objects, convert the keys to utf-8 and append the value (which will always be the hashed representation) and then sort these entries bitwise. And then hash all that.

Or, better, it'd be great to have an order-independent hash function that's also secure. I doubt xoring all the pairs would be good enough. Update: a possible technique[1]

[1]: https://crypto.stackexchange.com/questions/51258/is-there-su...

Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system

#98

Post by [deleted] »

Vendan wrote: post #31

Scuttlebutt is a neat concept, burdened by a bad protocol. Signing a message involves serializing a json object, signing it, adding the signature as a field on that json object, and then serializing it again. To verify, you deserialize the message into an object, remove the signature field, and then reserialize it, and verify the signature against that new serialization. This means that all the clients have to have a…

[deleted]

Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system

#99

Post by snicky »

Why does the users' data have to be stored in a form of a linked list (or "blockchain")? Couldn't every peer in the network just hold his own database full of messages and blobs and sign them with their private key when requested by an invited follower?

Edit: typo

Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system

#100

Post by muldvarp »

rakoo wrote: post #87
Vendan wrote: post #31

Scuttlebutt is a neat concept, burdened by a bad protocol. Signing a message involves serializing a json object, signing it, adding the signature as a field on that json object, and then serializing it again. To verify, you deserialize the message into an object, remove the signature field, and then reserialize it, and verify the signature against that new serialization. This means that all the clients have to have a…

Indeed, json maps are not supposed to be ordered so doing anything that depends on the order is bound to fail. This is the exact reason bencode ( https://en.wikipedia.org/wiki/Bencode ) was invented, and I still believe we can replace all uses of json by bencode and be better off it, because it solves all too common issues: - bencoding maps are in lexicographical order of the keys, so no confusion possible for hashin…

Interesting that your experience with Bencode was this positive. I've implemented a Bencode serializer/deserializer in Rust and here are a few things I've noticed:

* It is very easy to parse/produce Bencode

* It's probably fast

* The specification is really bad

* No float type

* No string type, just byte sequences. This is especially bad because most/all dictionary keys will be utf-8 strings in practice but you can't rely on it

* Integers are arbitrary length, most implementations just ignore this

I think Bencode is an ok format for its use case, but I don't think it should be used instead of json.

Post reply on HN