Photo by Kristina Flour on Unsplash

Overview of the Client-Side SkyeKiwi Protocol

— v0.2

We are very excited to announce that an early working release of the client-side version of the SkyeKiwi Protocol is open-sourced at http://github.com/skyekiwi/skyekiwi-protocol, with support from the Crust Network. This post will briefly go through what we have done so far and how to integrate the client-side SkyeKiwi protocol.

NOTE: the code is a very early version of the SkyeKiwi Protocol and is not yet audited by a third-party auditing agency. It is a heavily cryptographic-focused library, and we do not recommend using it in a production environment until the formal auditing has been done. Please be aware of the risk.

What does it do?

The client-side SkyeKiwi Protocol is a secret sharing protocol that is capable of sharing an arbitrary size of a file to hundreds of thousands of people over the public IPFS network, offered as a TypeScript library.

Why is it useful?

File storing and sharing is a basic element of the internet today. For blob storage, AWS S3 is possibly the best-known solution in the Web2.0 world, and S3 has some of the following characteristics:

1. Easy to use API
2. Controlled by centralized agencies. (i.e. AWS data centers)
3. Redundancy: Cross-Region Replications & Same Region Replications
4. Cost (us-east-1, north Virginia)

• Storage: est. $0.023. Per GB per month
• API calls: est. $0.005 per 1,000 request
• Data Transfer: Ingres — Free; Egress: $0.09/GB — 0.05/GB
• Cross-Region Replication: applicable data egress cost

Web3.0 blob storage (Crust Network in this example) — cool features are kept and the cost is much lower:

1. IPFS Compatible easy to use APIs
2. Controlled by a decentralized network of node operators
3. Redundancy: automatic redundancy across node operators
4. Cost:

• Storage cost: est. 1.7nCRU/MB per 180 days (given CRU at $50, the cost is about 0.0890188595 / TB / 180 days)
• API Calls: free for downstream, est. $1.7089792 / 1000 requests
• Replication & Data Transfer: included in the storage cost

Basically, the capacity of automatic redundancy and the cost of using Web3.0 completely blows S3 out. However, one significant drawback — all data pushed onto the network is published. The client-side version of the SkyeKiwi Protocol tackles this problem.

How to use it?

There are three simple high-level APIs exposed by the client-side version of the SkyeKiwi Protocol: {Upstream, Downstream, UpdateEncryptionSchema}. The name is fairly self-explanatory:

• Upstream(): takes in an EncryptionSchema, a FileHandle, a Key, and an IPFS client. Upon calling, it’s going to do all the magic behind the scene to turn the original files into a bunch of encrypted hex string chunks, sealed with a SealingKey, and post content to the Crust Network, while also log an encrypted metadata to a smart contract. The smart contract will generate an ID (the VaultId) that represents this file.
• Downstream(): takes in the VaultId generated from the smart contract, keys of the desired recipients. Then it will reverse the magic been done before and recover the file.
• UpdateEncryptionSchema(): is used when you want to update the sharing list to a new group of people, to change the visibility of the file, etc. It will not mess with the encrypted chunks but simply re-encrypt the SealingKey to the new desired recipients.

One special note on the EncryptionSchema, it represents the sharing schema of the Shamir Secret Sharing algorithm. In plain text, it means a sharing list and the visibility of the file of whether it is a public file or a private file.

And that’s it. We wrapped up all the magic within.

Some mentionable fun facts we built into it

1. As we mentioned in our previous post: because the SealingKey is 32 bytes, it can also be used as a private key for a public-key signature schema. Therefore, it is fairly simple to prove one’s accessibility or agreement to a file. When a file creator is publishing a file, simply record the public key derived from the SealingKey somewhere (i.e. in a smart contract). When the recipients want to prove that they have access to the file, simply sign a signature with the SealingKey, so that it’s public verifiable. We are using this feature to build a decentralized contract signing platform called KiwiSign. More blogs on KiwiSign coming soon.
2. Privacy: SkyeKiwi does not include the public key of the recipients in the metadata even before the encryptions. Therefore, theoretically, recipients do not need to know the public identity of other recipients or even the number of recipients. Upon downstream a file, the recipients will try to decrypt as many shares as possible, while those encrypted with their public keys can be decrypted and others cannot.
3. We run compression when upstreaming automatically, so the actual storage usage might be even lower than the original file.
4. We process data almost exclusively in byte streams. Therefore, the protocol is pretty much file-type agnostic.

Bottom Line

We look forward to learning how people use the client-side SkyeKiwi Protocol to build epic shit. Again, special thanks to Crust Network for sponsoring the development of this project. The SkyeKiwi team is also in the process of putting together a plan to launch a dedicated secret sharing blockchain in the Polkadot ecosystem which features Trusted Execution Environment (TEE), hybrid private-public smart contracts, secure distributed identity, natively built-in meta transactions, and native light-weight human-readable identity.

Stay tuned.

Drop us a message to:

Email: hello@skye.kiwi

Telegram: t.me/skyekiwi

Twitter: skyekiwi_team

Website: https://skye.kiwi