Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Encrypt and upload files to IPFS from browser (thirdcloud.org)
73 points by tri2820 on Oct 27, 2023 | hide | past | favorite | 40 comments
Hi HN, I'm building ThirdCloud with the goal to replace Google Drive for everyone: more private, cheaper & maybe better UI/UX.

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.




Encryption gets broken eventually as we get more compute power, and the current algorithms could have problems we're not yet aware of. IPFS requires every node to agree to your delete request (if I'm understanding it correctly).

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


> Encryption gets broken eventually as we get more compute power

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.


I remember reading Schneier's Applied Cryptography, where he mentioned Landauer's principle [1] and things like the entire energy output of our sun over an appreciable amount of time. If you play with it, you end up realizing that a 50 character line noise password is absolutely insane overkill (assuming you didn't realize that from other, unrelated directions.)

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.

[1] https://en.wikipedia.org/wiki/Landauer%27s_principle


> You can never straight up brute force a full-strength 512-bit key. That's just a fact of the universe.

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?


No? That's like saying "if my glass can fit a drop of water, then it can also fit an ocean". There is an upper bound to how much processing power there can be in the universe, and 512 bit keys need more than that to be cracked.


That's assuming classical computers though, right? What about future quantum computing developments?


I guess it depends on the algorithm they chose, HChaCha20 is the symmetric encryption algorithm for libsodium.js which is quantum resistant.

https://doc.libsodium.org/secret-key_cryptography/secretstre...

https://crypto.stackexchange.com/questions/79518/is-xchacha2...


Most if not all symmetric encryption is quantum resistant though (with a large enough key). Quantum computing only causes problems for asymmetric algorithms that involve factorisation iirc


The key words here are "brute force" -- there might be some [possibly quantum] techniques around it, but probabilities around guessing and checking an arbitrary number remain constant.


> What's stopping someone from just vacuuming all the data they can until codebreaking catches up with encryption?

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.


You can make blocks private in ipfs so only authorised people can download them. Here's how we do this in peergos https://peergos.org/posts/bats


>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?

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.


I uh, don’t think you understand how encryption works…


How is encrypted? Is it content-based encryption so files can be shared? How are the encryption keys stored?

Who is pinning the files in IPFS?

How are you planning on charging for storage? Are you going to use Filecoin?


It's encrypted directly on your browser, you can download the encryption key after file is uploaded. Not content-based (because the header is randomly generated & you keep the encryption key) but you can share to secret file to others and they will be able to download the file.

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).


According to NFTStorage's Terms and Conditions:

> 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?


https://web3.storage/ most likely


Isn't any file stored on IPFS by definition a NFT, since the address identifies a unique file?


Technically no, you'd need to also deploy a NFT smart contract that creates a new token for each file. But theoretically any media type could be represented by an NFT so it's sort of an arbitrary restriction by NFT.storage. Probably not super enforceable on their part. I imagine the promo will end at some point though. Filecoin just happens to have an excess of available storage right now, which is why they can afford to offer it for free.


It's hardly unlimited though. I can't even upload a 1.82kB image file to test it. Probably because whatever service it uses to access IPFS is saturated. So that wouldn't be unlimited in my book.

I love selfhosted stuff like IPFS, but keep expectations realistic or people will just leave with a bad impression of them.


You should consider fleek.xyz private gateway instead, you wouldn’t be violating tos, fleek use filecoin, and the sdk is more reliable. But it’s in alpha so you’ll need to request access on their discord. I’m a customer myself.


I was under the impression IPFS was a content addressing system with a p2p layer. Does ThirdCloud upload it to a pinning server?


Yeah, I'm uploading it through NFTStorage gateway (your files then will be pinned by many nodes on IPFS network)


What's the use case? If I have files, why should I store them on IPFS and pay someone to pin through all that complexity, rather than just use Google Drive or whatever?


This is amazing, great work! I love that it does everything in-browser.

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


That's a lot of questions ha ha, let me try to answer them:

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.


It's always very cool to see ShowHN posts result in a job offer. Seems to happen often enough here, but I never really see it on any other forum


Neato! My main concern is reliability of this type of service. Given the boom/bust cycle of crypto I have my hesitations.

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.


Booms and busts in crypto affect the market price, not reliability. Historically, blockchains with significant adoption and robust engineering like Bitcoin and Ethereum have had 100% uptime since near inception. Filecoin is newer (think the network went live in 2019), but since this relies on IPFS, you can also just back up your files in any other way (hard drive, cloud, etc) and the IPFS protocol will pull a file from any of several pinned data sources on the network.


I think curl added some support for ipfs recently. Saw a previous discussion here https://news.ycombinator.com/item?id=37628525


I could link a helper script to download the file later


Allow the user to decide if encryption should be applied to files or not.

I have files that are already encrypted.


I’m not arguing that you don’t have a valid point nor that the feature request should be beneficial for the project to add to gain wider adoption. I know why this feature isn’t there though, because doubly encrypting something doesn’t do anything but add another layer of protection they guarantee by default, but that the computational cost of this possibly not needed protection is assumed by the provider and not the consumer. On top of which other features have obviously been added before it, with an announcement of the service with the features that differentiate it from already available and established competing services.


A simple checkbox is all that is needed.


Sure


Not a big fan of hosting / supporting ipfs with all this garbage.

NFT and random encrypted backups


Looks cool, though I don’t trust the cloud when it comes to file storage.


This is sick! How are you handling pinning?


Could you add a delete feature, because not all data should live forever.


Not open source?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: