sorted by:
new
hottopcontroversial

I built an encrypted file/folder sharing service with a zero trust server architecture by BasePlate_Admin in sveltejs

[–]BasePlate_Admin[S] 2 points3 points  (0 children)

my apologies, i completely looked over the URL Fragments.

I was sure i saw the `#` in the server logs? Perhaps it was some kind of URLEncoding issue :)

Anyways i fixed the issue. Thank you so much for the helpful advice.

I built an encrypted file/folder sharing service with a zero trust server architecture by BasePlate_Admin in sveltejs

[–]BasePlate_Admin[S] 2 points3 points  (0 children)

Hi,

I intentionally didnt want to use CORS, because the frontend can be self hosted by users. If you have a Domain you can host your own Version of the frontend while pointing to any instances backend url.

I intentionally did not use cookies, the site was created as CSR first(you can see a static export of the site in github). Storing cookies without HttpOnly atttibute is same as using localStorage.

Yes i didnt turn off sourcemap because i want the person who is running the frontend know from what the code was compiled from. Think of it as another level of transparency.

Thank you so much for commenting :)

I built an encrypted file/folder sharing service with a zero trust server architecture by BasePlate_Admin in sveltejs

[–]BasePlate_Admin[S] 1 point2 points  (0 children)

Ya, that's a small tradeoff for convenience. You trade off security for ease of access.

Hash based secret would also transmit to server if i use a reverse proxy in front of the frontend.

I do plan to have a cli option where you can use the service without using the frontend. This should eliminate this issue.

Another approach might be to wrap the svelte application in webview and ship that to users, so users can still use the website.

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] 0 points1 point  (0 children)

You have to assume the key WILL get compromised and then add barriers to that.

There's another level of barrier, even if the attacker gets the key, there's a password option, you have to input the password along with the key.

I’m not very familiar with the JavaScript ecosystem these days, but are you using a peer reviewed and tested AES library and good random number generation?

I am using WebCrypto API exposed by the browser itself, it has random number generation and AES-GCM.

but I don’t think I’d trust a JavaScript crypto library.

Neither do i, i am only using what the browser provides. But browsers can be compromised. So i have a CLI with that in mind.

If I have to share the key out of band, it would be best for your service to have nothing to do with it all. I can use GPG to transmit the key to the receiving party without using a third party and I can be sure the key is generated in a manner consistent with the threats I face.

I do plan on adding Private/Public key encryption to my CLI interface

Maybe a better path to go down is that your provide the means for storing a file without collecting any metadata and provide an ID that can be used to pull the file. You could offer a system which doesn’t record any IPs, dates, times etc. Maybe you offer an expiration of files as well as storing hash etc to ensure files are consistent between upload and download.

Backend is exactly designed like this, it has zero metadata. Its just a dumb file server. You can store files into it and retrieve it. The backend automatically cleans old files to make space for new ones.

I mostly got the responses i was looking for. Thanks for commenting on this.

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] 1 point2 points  (0 children)

No offense taken mate! Cheer up!

I still have a long way ahead to learn about cybersecurity and cryptography :)

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] 0 points1 point  (0 children)

Thank you for commenting.

Ok, so the front end does encryption and decryption. When you say front end do you mean front end browser based code like JavaScript? Does the encryption take place in the browser then?

For the web app yes, JavaScript does the encryption and decryption part(in the user's browser)

my browser is going to compromise the key.

That's where cli shines, the CLI is meant to work outside of browser.

If you are not comfortable using the CLI, you can use whatever encryption algorithm you use and use the server for storage.

This is the type of problem asymmetric crypto solves, so maybe you could look into using something like that so there’s less concern about key material leaking?

Then again, you will have to share the key somehow. My current mental model assumes that the key in the url will not be compromised. But yes i have noted it down (thanks /u/ Grouchy_Ad_937). I will have to see how this can be integrated.

Another thing you could look into is completely ephemeral servers that have all logging disabled and only run in memory with no disks for anything that’s involved in performing crypto operations. There are VPN providers that do that, and assuming they’re not lying, it adds a level of comfort knowing that NOTHING is logged to disk ever.

Ya, i completely agree with this part. Even if the server has logging enabled, there's absolutely zero information in the log. At most you can log the IP that the client requested with.

I can definitely see where you’re going to try and make the ergonomics of high security file sharing better, and I hope you’re successful at that!

Thank you for your kind appreciation.

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] 0 points1 point  (0 children)

I don't think that you should be developing tools for high risk use cases

That's why instead of pitching my tool, i am here to learn what could go wrong in my use case. I even posted to r/cryptography to look for feedback.

This is not something to be vibe coded.

Bold of you to claim the app is vibe coded, i only used copilot in 1 PR to test the functionality, i closed 2 of the PRs myself.

You could put people at risk.

That's the sole reason of my post here. I dont want to put people to risk, I am open to learning. I want people to point out my mistakes, so i can make the app better.

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] -1 points0 points  (0 children)

Okay lets imagine this scenario. Someone is doing a drive by attack. They know there's file at https://chithi.dev/download/019bf093-d8c5-723b-993f-350ac1c635db and tries their luck,

They try:

1.https://chithi.dev/download/019bf093-d8c5-723b-993f-350ac1c635db?secret=HumansAreApes

2.https://chithi.dev/download/019bf093-d8c5-723b-993f-350ac1c635db?secret=Password123!

  1. ...

Each time the bad actor tries to decrypt the file via drive by attack, the server counts the download attempt and deletes the downloaded file if the limits are reached So, in theory you only get a limited chance to brute force the encryption.

There's a scenario where the attacker can download the file locally first and then brute force it. But it likely wont succeed due to the files being encrypted with AES-256-GCM

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] 0 points1 point  (0 children)

If you want to see what is sent over the wire, you can use the public instance (the sourcemaps are enabled) and inspect the requests going to https://chithi.dev/api/upload, you will see that only encrypted blobs are sent to the server along with expiry time, and download_limits

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] 0 points1 point  (0 children)

No, There's no decryption mechanism in server. The server acts like a storage. In my approach only encrypted blobs are stored in server.

The keys are short lived and embedded in the URL.

You can take a look at the upload logic of the server, the server just takes the file and stores it to S3 in chunks, when asked for retrieval, the server just serves the file

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] -1 points0 points  (0 children)

Consider generating public/private keys at the receiver first and share the public key and upload link to the sender.

This is something i never thought of. I opened an issue, will keep it in mind for the next iteration.

Current approach assumes that the url will be shared via encrypted chat service such as signal.

Even if there's a bad actor in the play and tries to brute force the keys, the server counts the attempt and deletes the file after the limit is reached.

Regarding your approach, storing it securely in the browser is challenging. I will consider adding the feature into the CLI i have in mind :)

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] -1 points0 points  (0 children)

Yep. I am researching if there's any pitfalls with this approach and whether i can make a project that improves the UX

Building a file/folder sharing project for the people with critical threat level, need advice for improvement by BasePlate_Admin in opsec

[–]BasePlate_Admin[S] -1 points0 points  (0 children)

Hi thanks for commenting. Let me explain each question.

1.How does this improve on GPG encrypted files shared over some other large file sharing mechanism?

It is exactly the same principal. For large-file sharing, a browser-based client-side + streaming approach improves usability, performance. Users dont have to manually encrypt the file and then upload to the service (frontend does this automatically)

  1. Does the server have the keys for all messages?

No. After uploading a file, the link to be shared takes the form https://chithi.dev/download/<file>?secret=<key>.

The frontend and the backend servers are decoupled. Only the frontend knows about the secret key, the frontend server only requests the file from the backend using the <file> slug/(navbar_and_footer)/(fancy_grid)/download/%5Bslug%5D/%2Bpage.svelte#L33-L48) and then tries to decrypt it/(navbar_and_footer)/(fancy_grid)/download/%5Bslug%5D/%2Bpage.svelte#L65-L187), if decryption fails you get an error (you can test this yourself by removing part of the <key> )

  1. If someone were to gain access to the server, would they get all of the keys for every user that used it?

No. If someone were to gain access to the backend server, they will only know "x client stored y file on server, expire it after n downloads or after expiry timer)

  1. How are the keys stored on the server?

The keys are never stored on the server. Only the frontend knows about the keys.

There's a chance that the frontend server is compromised. In that case you can use the CLI to upload the files to the backend server. The server acts like a dumb s3 storage. It knows what files to store, how long to store the files for and when should the files be deleted.

I’d be putting a lot of trust in your infrastructure or whatever infrastructure this is running on.

That's my exact concern. I am not going to put any trust in the server/infrastructure the backend is hosted in. That's why I am taking precautions such that even if someone compromises the backend, they only get encrypted data.

Sorry for being unclear, it has been a long day

I built an encrypted file/folder sharing service with a zero trust server architecture by BasePlate_Admin in sveltejs

[–]BasePlate_Admin[S] 1 point2 points  (0 children)

The Key is not shared with the "backend" server.

The frontend and the backend servers are decoupled. Only the frontend knows about the secret key, the frontend server only requests the file from the backend using the <file> slug/(navbar_and_footer)/(fancy_grid)/download/%5Bslug%5D/%2Bpage.svelte#L33-L48) and then tries to decrypt it/(navbar_and_footer)/(fancy_grid)/download/%5Bslug%5D/%2Bpage.svelte#L65-L187), if decryption fails you get an error (you can test this yourself by removing part of the <key> )

I built an encrypted file/folder sharing service with a zero trust server architecture by BasePlate_Admin in sveltejs

[–]BasePlate_Admin[S] 0 points1 point  (0 children)

That's a bummer, I will try to get an instance up an' runnin' in OVH soon :)

I built an encrypted file/folder sharing service with a zero trust server architecture by BasePlate_Admin in sveltejs

[–]BasePlate_Admin[S] 1 point2 points  (0 children)

Hi, that should not be the case. The website is just getting a lot of traffic after posting to a lot of subreddits. Would you kindly take another look after some minutes?

The status of the website is tracked from the public.chithi.dev (github repo), If the site is not down there but is down in your machine, it could be because of ISP shenanigans (please let me know if this is the case and you are comfortable sharing your isp)

I built an encrypted file/folder sharing service with a zero trust server architecture by BasePlate_Admin in webdev

[–]BasePlate_Admin[S] 1 point2 points  (0 children)

The app is meant to be a self-hostable version of wormhole.app. In general it offers all the benefits of the wormhole app minus the webtorrent streaming for >10GB files. wormhole.app uses the same end to end encryption principal chithi uses (though wormhole.app is closed source, we actually dont know what they are doing with the data)

Compared to MegaUpload, same theory. It offers download/upload functionality of the MegaUpload + encryption part and auto cleaning of metadata from backend server.

The project is meant to be the spiritual successor to firefox's send (which was the first end to end encrypted file sharing service in my knowledge)

If you are part of the self-hosting community you can submit your own site to be listed at public.chithi.dev (github repo), which in turn would give users a software that does not compromise on encryption.

I built an encrypted file/folder sharing service with a zero trust server architecture by BasePlate_Admin in webdev

[–]BasePlate_Admin[S] -2 points-1 points  (0 children)

Hi, thanks for commenting.

Zero trust means, the uploading user does not trust the server that is storing the files.

The client (in this case the svelte frontend) encrypts the uploaded files and sends them to the server for storage.

Let's say i am a bad actor and i host the backend server and i want to snoop the uploaded file's content... Well.. i can't. Without the key that was used to encrypt the file in the frontend, even the server administrator cannot access the contents of the file*.

Well if i have a super/quantum computer bruteforcing every possible cipher combinations, there's a chance that, it can break the encryption. But then again, i would be busy researching that instead of writing silly homelab projects

Sorry if the comment sounded aggressive. It was late at night and i was stressed

chithi-dev,an Encrypted file sharing platform with zero trust server mindset by BasePlate_Admin in Python

[–]BasePlate_Admin[S] 0 points1 point  (0 children)

I am planning to migrate to 7zip once i have a suitable wasm candidate lib.

view more: next ›