thirdcloud.org
So far, I've successfully implemented the main feature, which involves uploading and downloading files. Files are encrypted before being sent to IPFS network.
Would like to hear your thoughts on this proof of concept.
What's stopping someone from just vacuuming all the data they can until codebreaking catches up with encryption?
Is there a way to remove malicious content? For example, if someone uses this to store some malware's payload and you don't want your project being used for that, what happens?
That said, IPFS is cool, and this project is a neat application of it
My job involves fighting malicious content on the internet. No, there's no way to remove malicious content from ipfs. It's especially annoying when the ipfs2http gateway takes path using a GET parameter (instead of it being a part of a domain name) because it makes it unblockable on the DNS level.
The people who have the time and resources to do this are nation states. And if they're going to spend their resources on IPFS, they're also already doing this for intercepted HTTPS traffic because it would be wild not to. Imagine having the confidence to crack strong encryption and ignoring 99.9999% of web traffic so you could potentially spy on the handful of gigabytes of whatever is ending up on IPFS.
Even if codebreaking catches up to the point where it's tractable to start cracking the encryption on these files, the ability to tractably crack _all_ the files is probably many decades away. You can probably be confident that you'll be long dead. And you can almost certainly be confident that by the time any of the files (or HTTPS traffic, or whatever) get cracked, the statute of limitations has long passed on whatever nefarious thing you are worried might get seen.
Of course privacy from the prying eyes of the NSA (or your favorite codebreaking entity of choice) is obviously important, but it really begs the question: what is their incentive to do this? To get in on the furry porn you're uploading? To see your baby pictures? The kinds of secrets the NSA is looking for need to be worthwhile enough for the NSA to justify spend millions (billions? tens of billions?) of dollars building zettabyte-scale data centers and cracking them years and years after the fact instead of spending that money on something more immediately impactful. Quite frankly, those secrets aren't "someone from HN sharing their files over ipfs"-shaped.
What, no. Encryption gets broken only because we find weaknesses, not because compute power increases.
You can never straight up brute force a full-strength 512-bit key. That's just a fact of the universe. If the scale of your attacker is less than "literally the whole universe since the beginning of time", 256 bits will suffice against any future human developments.
But even less capable encryption is fairly strong. I would find it unlikely* that a single 3DES-encrypted message (a standard from 1981 with 112 bit effective key length) will be brute-forced, even with novel cryptanalysis, in your lifetime.
Even quantum computers won't help substantially for the capability in breaking a symmetric-key algorithm. Maybe** that 3DES message from 1981 can be broken with them, but any modern settings will not be.
*Unlikely as in less likely than not. I would be surprised if this happens, but the example here is to indicate that even obsolete messages don't have any constructive breaks against them, not that all 3DES messages are secure
**This would be a huge win for quantum computers, beyond imagining for now. But even with this huge win, you can't make such headway for a 256-bit key.
If there is some number of bits n < 512 where brute forcing an n-bit key is not a "fact of the universe", does it stand that cracking 512 bit keys is also not a fact of the universe?
https://doc.libsodium.org/secret-key_cryptography/secretstre...
https://crypto.stackexchange.com/questions/79518/is-xchacha2...
Cryptography benefits from having a larger than practical keyspace due to what happens if the algorithm is weakened beyond brute force. But this happening isn't a given.
Who is pinning the files in IPFS?
How are you planning on charging for storage? Are you going to use Filecoin?
Files are pinned mainly by NFTStorage.
Currently it's free because NFTStorage is free. If things change I would allow buying storage using Filecoin (~$0.2/TB/month).
> The Service is offered for the creation and storage of NFTs. Use of the Service to store other types of data is not permitted.
Do you have a special agreement with NFTStorage which overrules the general Terms and Conditions?
I love selfhosted stuff like IPFS, but keep expectations realistic or people will just leave with a bad impression of them.
A handful of questions:
Your currently uploading to a gateway and are considering moving to your own gateway backed by filecoin. Have you considered ditching the gateway and using the libp2p WebRTC and/or WebSocket transports to upload directly to the network via the browser tab?
Where are you hosting this and how are you protecting against "supply chain attacks" where your hosting provider (either maliciously or through their service being compromised) injects additional JS that exfiltrates secrets? Have you explored managed/trusted upgrades to the existing user's apps through browser storage and a service worker? I don't know of any surefire ways to protect against the first delivered page being compromised, or a compromised browser environment, but could you lock down the upgrade path for the app for returning users by moving it outside of the page load path? (Not just a question for OP, I've been wondering about this for a bit now, it's kinda critical path for delivering P2P experiences to a browser tab - you need a way to minimize trust of the server hosting the HTML/JS files otherwise it can trivially exfiltrate your secrets)
What is the migration path off of this? If I have this metadata file, how do I use it locally to fetch my encrypted files directly from the IPFS pinning server without having to return to your site?
How does multi-user access work?
What do you think the path to beating Google Drive on UI/UX is with P2P software?
---
We are working on a very similar problem to this right now, using the guts of IPFS and some stuff borrowed from Secure Scuttlebutt et. al. to manage encrypted files, identities, and capabilities. We also have a way to encrypt a file once and share individual per-user encryption keys on-demand bound to the user's private key. This lets the decryption keys be mirrored by nodes (i.e. put it on IPFS!), without the corresponding private key the decryption key is worthless. Next we are exploring UCAN for managing capabilities and granting access. And an overlay network to power it all. I'd love to compare notes with you.
Do you want a job? There is an open spot on my team working on exactly this stuff. Our goal is to make an SDK for building these exact types of apps.
Salary bands max out at $250k. Fully remote team, nomad friendly, 4 day work weeks. Time is spent roughly 50/50 implementing stuff and reading research papers (like Filecoin, IPFS, Scuttlebutt, etc.).
We have an open interview challenge for the team that gives some good insight into what the role is and what a "day in the life" will be like: https://gitlab.com/webai-open/network/interview-challenge
I have used libp2p a while ago (for another app), at that time libp2p WebRTC was not ready yet. Now that you mention it maybe I should check them out again.
Currently I'm hosting on Vercel. I tried not to put too much thought into making the app 100% secure but rather only secure enough for a "normal" user (making file upload encrypted by default is what I think needed to make IPFS usable for them). There are potential problems that you listed there that may or may not be solved by offering a frozen versions of of this app on IPFS itself. No idea how to solve compromised browser env / hardware. It's really a rabbit hole.
About migration, I will add a simple Python snippet to fetch the files so you don't have to visit the site.
Multi-user access: I think the hard part is to allow revoking access. Once someone has successfully decrypted and read the file, they already can download and keep a copy of it. So the only thing I could do is to stop them from continuing accessing the file through ThirdCloud services (maybe just by revoking a particular share key). The tech you are doing seems to be about signaling nodes to revoke the share keys (or more like "revoking by default" - only give access after checking back with your main node)?
Have not thought much about UI/UX. I just like the fact that my files now are now 100% not locked down (while still being super convenient to access). Remind me of the time when I keep an offline collection of mp3 songs and can upload them to different mp3 players (but now I don't have to upload because it's already in the cloud). Maybe letting ThirdCloud having an extension ecosystem is the path?
--- About the job, have reached out to you on LinkedIn. Not sure how this turns out but would just love to say hi.
Anyway to download a file via curl? I wouldn't mind setting up a cronjob to periodically download a testfile to track the reliability over time.
I have files that are already encrypted.
NFT and random encrypted backups