The game is simple. You've got access to documents and we want you to leak them.
BYRD is a distributed network that allows you to share and access content with plausible deniability. Files are encrypted, shredded, and disbursed all over the network. The chunks can be later retrieved and reassembled on your computer by using an easy to remember "alias".
Use a web browser on a desktop or mobile device, and open the site http://counterpoint.2015.nodeknockout.com The UI allows you to do 2 things.
You can distribute a file to the network, and give it an "alias" name, which can be shared verbally or otherwise with someone else you want to share the document with. When a file is distributed on the network, it is first encrypted, and then the pieces are sent to different nodes on the network. The operators of the network nodes cannot read the files. They will each only have small, unusable pieces of an encrypted file.
A person who knows the "alias" of a distributed file can use our web application to reassemble the file and download a copy of it.
If for some reason, the process appears to be "stuck", simply refresh the browser and try again.
The following Node.js libraries were used: "body-parser": "^1.14.1", "config": "^1.16.0", "ejs": "^2.3.4", "express": "^4.13.3", "winston": "^2.1.0"
Icons provided by IconMonstr.com
We are also using an external REST API that wraps a Kademelia DHT (Distributed Hash Table). This API is running on 3 EC2 nodes, as described in our app's README: https://github.com/nko5/counterpoint.
We discussed this via email with Jacques Crocker @ nodeknockout.com, and they ok'd it for our use case.
Jacques Crocker has been provided with root access to these 3 EC2 machines to ensure they are really only running the open source project https://github.com/niahmiah/kad-rest, and to make sure no tampering will take place after the contest ends.
The reason we needed to use external hosts was because the API needed to expose 2 ports, and we needed multiple instances for the DHT to work.
Voting is now closed.
Thank you! Sorry to hear you weren't able to distribute the file, the implementation we were able to complete within the timeframe can be nondeterministic, so sometimes just giving it a few tries will work.
We have made significant improvements since our final deployment, so keep up with us after the competition at: https://gitlab.com/counterpoint/byrd
Thanks again for your time!
You're welcome. I'll make sure to keep up with developments on the application.
I'm sorry you didn't have any luck!
Yes, SSL is a must for production nodes. Thanks for your time and feedback, Carlisia!
Can you explain what you mean?
Only so many "names" out there. unless we start getting into totally non-sensical stuff, and at that point you may as well be spitting out a random string on upload that the user can copy.
It also doesnt seem to recognize names that are already taken.
Is there anything going on to ensure the files are clean?
The file chunks are actually content addressable under the hood (keyed by their hash). We actually wrote the code to do naming on the bitcoin blockchain but ran out of time for the blocks to sync, so instead right now the name <--> file blueprint get stored in the DHT and is not content addressable which is why for this demo names can be overwritten.
The idea is that you can look up a file by the hash of it's blueprint or you can register an alias name by signing a bitcoin transaction (incurring a small fee). But again, in the time we had, this is wasn't fully implemented. Soon after judging we will show the blueprint hash (your aforementioned "random string") and give the option to "buy" a name alias (for fractions of a penny).
In regard to ensuring files are clean: due to the nature of the design of the program (plausible deniability for storage operators), its not possible to inspect the contents of any distributed files. This is because nodes only have small encrypted chunks of different files without context and no single node stores all of the chunks for a given file.
Thanks, we believe there are two reasons why:
Lots of non native crypto happening synchronously in the browser - performance varies across devices but I think we can optimize to where it's usable for larger files
Available infrastructure for the competition for the delivery of file chunks - this is a distributed system, but there are only 3 nodes running during judging
Bummer man! There are definitely some kinks, but it should be usable! Can you share with me your browser or the nature of the error?
Thanks! We will have complete documentation and test suite soon as well as spin up a few more nodes after the competition is over!
Due to the nature of the system and its intent (which is plausible deniability for storage operators) it's not feasible (or desired) to provide file aliases since they are not known (they only know that a hash maps to a series other hashes which are then used to query the network for encrypted file chunks). This means that no single node has the entire encrypted file or is aware that a given name maps to the file "blueprint".
Thanks a lot!
The name overwrites are a problem. We have a branch that uses the bitcoin blockchain to register names to prevent re-use but ran out of time. This will come after judging!