Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent tampering #39

Open
pocesar opened this issue Nov 27, 2014 · 7 comments
Open

Prevent tampering #39

pocesar opened this issue Nov 27, 2014 · 7 comments

Comments

@pocesar
Copy link

pocesar commented Nov 27, 2014

I'm trying to wrap my head around the concept, I have the understanding about bitcoin blockchain technology (or others that followed) but I don't seem to understand how scuttlebut can ensure consistency and prevent someone meddling with the intermediate data.

At the first initial sync phase, that are 2-3 nodes, so later it can receive more clients, how can it ensure that node 2 didn't create a copycat of the open source project that it's sole purpose is to wreak havoc on the data that is being communicated between them?

@dominictarr
Copy link
Owner

@pocesar secure-scuttlebutt uses signatures and hashes.
If you know the hash of my public key, then you can verify the messages I post.
Messages are arranged to a chain like in bitcoin, but with signatures instead of proof of work.
(so we each get our own personal chain) the first message in the chain contains the public key,
and every message after that contains the hash of the previous message.

Since a mitm cannot interfere with a message, because the signature would be wrong, and could not leave out a message, because there would be a gap in the chain of messages. They cannot just give you a different chain, because you already know the hash the public key would have.
The worst they could do, is pretend they don't know about new messages from a feed, this would only delay the time until you are able to get them, since you might hear about those messages from other nodes instead.

@pocesar
Copy link
Author

pocesar commented Nov 27, 2014

@dominictarr I see, so it would be able to hold encrypted personal data without having to worry about it being tampered? (using secure-scuttlebut that is). And does it have a way to use "authority" nodes, that have more height than another, to ensure integrity? or it's not needed?

@dominictarr
Copy link
Owner

oops. I didn't realize that this issue is on scuttlebutt. I thought we where talking about https://github.com/dominictarr/secure-scuttlebutt.

You are correct, this is insecure. We did experiment with securing this https://github.com/dominictarr/scuttlebutt/blob/master/security.js

Ideas which where further developed in the new project, secure-scuttlebutt which IS secure, as I described.

@dominictarr
Copy link
Owner

Basically, secure-scuttlebutt (data layer) and scuttlebot (networking layer) and phoenix (user interface layer) are built on some of the ideas in this repo, and most importantly, add a lot of security.

Even in the original experiments (see the ./security.js file) messages where signed, but a mitm could still drop messages, so you can't know whether you have the entire set... However, in the new projects, this is not possible.

@pocesar
Copy link
Author

pocesar commented Nov 28, 2014

@dominictarr so secure-scuttlebut is enough to keep personal data encrypted but replicated?

@dominictarr
Copy link
Owner

@pocesar no, there is no encryption, just signatures and hashes. It's focus is on replicating data securely, and then privacy may be implemented atop of that, by encrypting the messages that are securely replicated.

@pocesar
Copy link
Author

pocesar commented Nov 28, 2014

@dominictarr thanks for the info, this is a clever piece of software ;) I'll be using secure-scuttlebut on a sidechain open source module, that's why all the questions, because blockchains per se are very secure the way they are designed, and I wouldn't want to add a layer on top of it just to be the weak side

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants