A super secure decentralized file sharing application powered by Web 3.0
Hako uses protocol called proxy re encryption to secure and permission data efficiently.
Unlike other file sharing services such as Dropbox and Google Drive, Hako does not place your keys in the hands of a large companies. The user is always in control of your keys and your data.
Centralized storage has a single point of failure (the company) and require a user to be online (connected to the central servers) in order to transfer data and delegate access.
just signup here and then upvote the two projects: https://coinlist.co/register
The future of the web?
Hako leverages Web 3.0 peer to peer protocols so users can directly share data, as well as a live distributed nucypher network — or a federated network (like on run on a local machine) or run by some central body you trust (a bank, a school, a 3rd party you pay for).
Hako has no single point of failure and allow non-trusted 3rd parties to delegate access to data — while never being able to decipher the original message.
Y.O.E.O not Y.O.L.O
Aside from the added network resiliency and cryptographically secured network. Hako follows a Y.O.E.O (you only encrypt once) methodology which saves huge amounts of data.
Instead of duplicating and encrypting a message for every user you’d like to share with. You only encrypt the data once, and do transformations on the keys to allow other users access.
How’s it work?
If you were to share a 1 TB file with 5 people, you would save 4 TB of encryption time and 4 times the amount of computational run time.
Hako allows for secure and efficient data sharing. It relies on 100% open source protocols that encrypt data with full transparency as well as leveraging content identifiable addressing and zero knowledge proofs for data integrity.
Why it was built?
Hako was born out of the NuCypher + Coinlist hackathon. The project is actually two parted, and consists of a library called NCIPFS and the application Hako. Hako is powered by NCIPFS and is provides a REST interface and web-app to the underlying methods of NCIPFS.
It is important that we break down Hako into its smaller pieces to get a full understanding of what it enables.
It’s not that useful to know how Hako was built (whilst traveling through Japan, on trains/planes and in wifi permitting coffee shops) but why it was built the way it is.
First people ask, why another file sharing app?
Well this is easy — with the developments of more powerful/resilient communication protocols it seems obvious that we would port our most useful applications to a peer to peer web.
One with no central body, one that is offline first, is cryptographically secure and people powered.
Second people ask, what is a Futari?
Futari actually means “two people” in Japanese and seemed like an apt name for the Hako user (a combo of an Alice and Bob role). Futaris have the ability to encrypt data before they place it on IPFS and also can receive data from other Futaris and subsequently download/decrypt the data from IPFS.
Alright so… Futari is simply a fancy name for a user. Yes true — but it means exactly what is it, and in Hako we don’t have users. We have Futaris.
Now that were familiar with Hako participants — we need to understand what people are sharing.
Since data on IPFS resides on all the locations that is it’s requested we don’t want to send a file, we simply want to share the location (and content hash) with individuals of interest.
However the paying attention reader will notice that the CID doesn’t really share anything of value — all the CID points to is an encrypted bucket of bits. Not useful for anything but wasting space on your computer.
So we need a way to pass the information that would allow a person to request the appropriate re-encryption keys or in human terms — all the info needed to unscramble the bits into the original file.
The data needed for is 4 parts:
CID + POLICY KEY + SIGNING KEY + FILENAME
We concatenate all these values together with _'s and create what we call in Hako the NUCID
Wait whats a NUCID?
It’s simply a special identifier we use in Hako to fetch a file and the respected policy for that file. If a person has been granted access by the file’s originator (the Futari who uploaded it) then they should be able to decrypt the file with their own keys.
This is the magic of NuCyphers proxy re-encryption in play. It allows us to encrypt the data onetime and then create policies where we allow others to decrypt the data with their own keys (unbelievable; I know) but like any other magic trick — with a peep under the hood we can see all the beautiful mathematics that make this work. Shout out to the geniuses at NuCypher for developing these cryptographic primitives. 🎉
The NUCID is simply a serialized string that contains all the data we want in a short (double clickable way). The NUCID is purposely encoded using Base58 so user can double click any part of the NUCID and the device will automatically highlight the whole NUCID (this would not be the case with higher base encoding).
Wrapping it up
So we’re now familiar with the Futari, the NUCID and Hako in general. We see the value of a distributed file sharing app and a simple way to interact with IPFS, and NuCypher without knowing anything about the underlying workings.
- We can share files with who we want, how we want.
- We can secure data with time tested symmetric encryption algorithms
- We have an easy to use web-app that works on our browser and mobile device.
- We have a developer friendly library (NCIPFS) to interact with IPFS and NuCypher easily.
- We have extendable concepts that can be reused in other implementations of distributed data stores and privacy layers. (the Futari and NUCID).
- We have a two part submission for the hackathon. One dev tool and one application.
If your itching to try out the demo via cloning the repo, jump to the bottom of the article, however we might want to better understand who will use this app and how they can use it. What benefits it brings to those users and short examples of their usage patterns.
To start, make a new Futari by clicking create when the app loads.
Next the page should reload and now we can login.
Now we’re at the home screen and can do a few different things!
If someone has already shared a file with you and added a policy to allow your newly made Futari access you should have a NUCID ready to download and decrypt.
You can enter that NUCID in the nucid bar at the top of the app and click GET to retrieve your file.
on the other hand, if you do not have a file to download and want to upload your own encrypted files to IPFS just click the 💾 symbol and a drag-and-drop box will appear.
You can add files up to 4GB (at the moment — chunking for larger files is yet to be added, this is a limitation of the core symmetric encryption algorithm)
On a desktop you can drag and drop on mobile just tap that grey pane and you will get a menu like the following
Once a photo or file is selected, a series of behind the scenes processes will start.
- File is converted to a multipart upload and is sent to the Hako server
- The file is encrypted with the current Futari’s Alice encryption keys.
- The encrypted file will be stored in IPFS. In return a CID will be sent to the application.
- Hako now re-encrypts the data for your Bob keys. This way even if we change pier Alice keys, we can access the data.
Yay 🙌 we now have the file successfully encrypted and stored in IPFS, as well as access to a decrypted copy of the file (since we granted ourselves permission).
We can see our files in the file list now and have a few options on what we do next.
Theres a lot happening on this table so we’ll look at each column individually.
Label — is the human readable file name — we truncate it for the view but if you hover over it, you can see the full filename.
CID — this is the content identifiable address, kinda like a URL but the identifier in IPFS. Anyone can fetch the bytes at that address but if you do not have access it will return a bunch of encrypted gibberish. Try it yourself and aceess that CID at your favorite IPFS gateway like:https://cloudflare-ipfs/ipfs/YOUR_CID_HERE and you can see what I mean about it being gibberish.
Size — is the human readable file size once it has been encrypted and placed on IPFS. You’ll notice that this file size is slightly bigger than the original file. There is a small amount of overhead needed to allow for NuCyphers re-encryption schema.
Open — now we get to the clickable options. Here we can open and view the file! You’ll be able to see the decrypted file contents (assuming you have access)
Permission — This is how we add policies and viewing permission to a file. When you click on this 🔓 you’ll be prompted to choose or add a Futari to share the file with (covered in more detail below)
Policies — is how you can see who the file has been shared with. If you uploaded the file, you should see your Futaris name since Hako automagically allows yourself viewing access to your own files.
Now that we have our files added and we understand the file table, we’ll want to start sharing files with friends, coworkers, or maybe even our doctors.
In order to share a file with someone- we have to first add their Futari’s recipient keys (or their Bob keys in NuCypher world) to our contact list.
Once we add them as a contact we can share any file with them we want.
Just click on the 🔑 symbol on the top bar to copy your keys to your clipboard.
Note we also copy the username so others know what to call your Futari
Once copied you can send them however you want to another person (email, slack, carrier pidgin).
Note: these keys are *public* so no worries about accidentally sharing them.
The only thing someone can do with these keys is allow you access to their Hako secured file.
We want to share the photo we just uploaded, so we click on the 🔓 symbol and are prompted to add a contact.
So far we have no contacts so we’ll copy some keys over from a demo Futari’s I made earlier.
All we need to do is copy their keys (and username) they sent into the input box and press add.
Yay 🎊, now we have a contact whom we can allow access.
Cool. 🤙 when we grant access a multi step process is kicked off behind the scenes.
- A new policy is made for the file in question.
- The policy is sent to the NuCypher network and distributed across the nodes.
- Hako created a NUCID for the policy including the files CID and human readable file name.
- Hako updates the UI to reflect the new Futari who we’ve granted permission.
If we click on their name, it will copy the NUCID to our clipboard and we can share this with them. Once again this can be publicly shared and has no value unless you are that Futari. You’d need their Bob private keys to make use of the NUCID.
Done ✔️✔️✔️ We’ve now successfully added a file, granted ourselves access, viewed it in the app, added a friend and granted them permission as well. We’re all done with our part.
For completeness we’ll login to our demo Futari we just shared the file with and retrieve, download and decrypt it.
We’re in and now we just need to copy that NUCID over and paste it into our NUCID bar.
Simply press GET. And voila ✨ the files is added to this Futaris file list
At a quick glance you can see the file sizes are the same size and have the same filename/CID. Looking good.
We can ensure that the data was correctly decoded by clicking the 📖 button and viewing the image.
We now have seen an end to end process of securely sharing data using Hako! Not to hard, and we keep the highest level of security, we share the data in a peer to peer manner and have no security leaks 👏
What if someone else sees that NUCID?
To show the complete security, we also will login as another user and try to decrypt the file from that NUCID shared above. Since the photo originator didn’t grant this user access they should not be able to see the decrypted photo.
We login as a user named xyz.
Using that same NUCID that Abc decrypted — we copy that into our NUCID bar
A file is returned…. But its tiny — 17 bytes. (this is actually a nullified response we get when we try to request re encryption keys from NuCypher.)
Opening the file shows the same CID on IPFS, but the user cannot actually see anything. They are not granted access which causes their decryption attempt to fail.
Great! We’ve successfully shared our file with one person, but only encrypted it on IPFS once
Note: since IPFS is immutable — the same CID proves that we only encrypted the data once.
Sharing large encrypted files with many people
One great example of a user would would benefit from Hako, is a person who wants to share a large secured files. Since Hako only needs to encrypt the data and store it once. It removes storage redundancy for each person you share it with.
Instead of having many copies of the same data encrypted with each of the recipients keys. We just store it once. Yay to saving huge amounts of storage space. Think about the implications of a 5gb file, or a 100 TB file! That’s full hard drives amounts of savings.
Sharing sensitive data with multiple participants
Another great example, and a primary focus of other NuCypher apps it the ability to selectively share private data with who you want. Take medical data for instance.
Let’s say you store a copy of your DNA sequence in Hako. This is very sensitive data that you only want certain people to have access to. Let’s say you move to a new city and want to share your data with your new doctor. Traditionally you would have to have a copy of the DNA (not encrypted) and then when you find out your new doctors public keys you could encrypted that data, store it somewhere and then they should be able to decrypt it. However when using Hako, the data is already encrypted and stored on IPFS, all you need to do is add your new doctors public keys to your files permissions, this would grant then access to retrieve your DNA sequence from IPFS and decrypt it. No need to move data, no need to re encrypt and you get to share the data how you want when you want.
Sharing data offline
Another awesome use of Hako allows users to share data offline. IPFS is an offline first protocol that does not require a persistent connection to the rest of the web. If one opts to use a locally hosted IPFS gateway — and run a small NuCypher federated network locally. They can achieve all of the security and data sharing benefits that an online Hako user would have.
The offline user could be in an area where internet is unstable or not available. This could be in a country where governing bodies attempt to censor data transfer. In both cases Hako could be used to share, permission and view data between parties. Hako is built to be offline first, to preserve security and data integrity and be easy to use. No matter your connectivity to the rest of the world- you should be able to share information securely.
There are many other uses that Hako enable and the user stories above are just the start.
There are many developments in the underlying technologies that enable Hakos awesome features. NuCypher for instance is working to release NU tokens — which will enable a truly distributed network for access control. IPFS is soon to be native in browsers like Chrome and is already available in Brave (as a dev branch, not publicly released yet) so accessing IPFS files will be as easy as any http site.
The future is bright for distributed web technologies and Hako is just the beginning of powerful ways to share data.
Hako was made in less then 4 weeks and is still in alpha stage for the hackathon. There is a lot of work to be done to make Hako the premier data sharing app for Web 3.0 and development will be continued after submission. Please help us make Hako more awesome! Check out the demo, leave a comment, clone the repo and make some pull requests. Hako is by the the people and for the people!
GIF demo and how you can try it
In order to access Hako fully, please clone the repo and run the app on your computer. This way you’ll be in charge of all your own keys and you can even run Hako offline.
https://github.com/drbh/ncipfs is the library that handles NUCIDs and Futari’s. It connects to IPFS and the NuCypher network of choice. This is a developer friendly library that can be integrated into many applications.
https://github.com/drbh/hako is the web app that provides the UI and sever endpoints for Hako to run. This could be hosted or run locally. Hako also handles all the keys related with a Futari so it should be kept in a secure running location.
Note: You’ll need NCIPFS to run hako .Hako expects to find the NCIPFS library in the same directory as Hako, however this can be easily changed in the server file.
A demo video
The above GIF was created from this youtube video. Check out the video if your interested in scanning the demo at your own pace.