Live data from Hacker News

Show HN: Encrypt and upload files to IPFS from browser

thirdcloud.org

31–40 of 43 posts

Re: Show HN: Encrypt and upload files to IPFS from browser

#31

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…

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

Re: Show HN: Encrypt and upload files to IPFS from browser

#32
post #31

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…

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

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

Re: Show HN: Encrypt and upload files to IPFS from browser

#33
post #31

Earlier quoted context omitted.

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

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

Re: Show HN: Encrypt and upload files to IPFS from browser

#36
post #31

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…

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

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

Re: Show HN: Encrypt and upload files to IPFS from browser

#37

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…

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

Re: Show HN: Encrypt and upload files to IPFS from browser

#38
post #33

Earlier quoted context omitted.

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

Re: Show HN: Encrypt and upload files to IPFS from browser

#39

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 "supp…

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.

Re: Show HN: Encrypt and upload files to IPFS from browser

#40
post #33

Earlier quoted context omitted.

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

Post reply on HN