javascript encrypted persistance
im working on a javascript UI framework for personal projects and im trying to create something like a React-hook that handles "encrypted at rest".
the react-hook is described in more detail here. id like to extend its functionality to have encrypted persistant data. my approach is the following and it would be great if you could follow along and let me know if im doing something wrong. all advice is apprciated.
im using indexedDB to store the data. i created some basic functionality to automatically persist and rehydrate data. im now investigating password-encrypting the data with javascript using the browser cryptography api.
i have a PR here you can test out on codespaces or clone, but tldr: i encrypt before saving and decrypt when loading. this seems to be working as expected. i will also encrypt/decrypt the event listeners im using and this should keep it safe from anything like browser extensions from listening to events.
the password is something the user will have to put in themselves at part of some init() process. i havent created an input for this yet, so its hardcoded. this is then used to encrypt/decrypt the data.
i would persist the unencrypted salt to indexedDB because this is then used to generate the key.
i think i am almost done with this functionality, but id like advice on anything ive overlooked or things too keep-in-mind. id like to make the storage as secure as possible.
Shared VR space over P2P
https://github.com/positive-intentions/chat
the code related to the video is a faily basic implementation using BabylonJS. it can be found here.
id like to see if i can get handpose-estimation to work well enough to be able to add to the BabylonJS render engine.
im working on something i hope will work like the 8thwall demo here. i couldnt find an open-source alternative to this so i thought id have a crack at it myself. my progress so far is as described here. i dont have much experience in creating games or graphics, so any guidance/help/advice is appriciated.
FAQ:
- why should i use it? - its a proof-of-concept app. for testing and demo purposes only.
- why create it? - it is a hobby project and i can be creative with the approach. its fun to work on.
- what is it? - maybe this article helps.
The frontend and the peerjs-server are open source and selfhostable independently. This should address any third party concerns. Perhaps the app can only be considered secure if it's self hosted?
Shared VR space over P2P
https://github.com/positive-intentions/chat
Experimental work in progress of a proof of concept.
How can I describe the chain of trust in a self hosted system? I'm sure auditing will help inspire confidence but this isn't something I can do for the app. Open sourcing is the next best thing to open it up to public review.
Cool! I haven't come across this one before. Thanks for pointing me to it.
Browsers, operating system and peers can become compromised.
Ultimately users have to be responsible with how and who they connect to. The app otherwise is only as secure and as restricted as any other website. As a web app there are nice features like being able to inspect network activity and code.
A typical mainstream browser can be considered to have been sufficiently reviewed. But you aren't limited like you would be if the offering was from an app store.
I'm genuinely curious why neither have a webapp offering. You can avoid the official app stores by providing things like APK, but as a webapp you can avoid the installation step, which seems it might be useful for people who would use briar or simplex.
The way this app works, makes it so "anonymous" chat isn't possible. With IP's being shared it isn't a good idea.
I also have quite an ugly UI compared to those other solutions. This will improve over time. But im sure it's a barrier to attracting users compared to other chat apps.
Is This The Most Secure Messaging App?
https://github.com/positive-intentions/chat
probably not... Because I'm comparing it to everything... but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify... but i want to understand why?
im not a cyber security expert. im sure there are many gaps in my knowlege of this domain.
using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman over webrtc (which can be considered secure when exchanged over public channels)
-
i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.
-
another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages for free and instructions are provided. im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.
-
to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.
-
i often get touted things like the Signal/Simplex protocol is amazing and great, etc. id like to compare that opinion to the observation in how my todo app demo works. (the work is all experimental work-in-progress and far from finished). the demo shows a simple functionality for a basic decentralized todo list. this should already be reasonably secure. i could add a few extra endpoints for exchanging keys diffie-helman style. which at this point is relatively trivial to implement. I think it's simplicity could be a security feature.
i think if i stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the frontend and the peerjs-server to be hosted independently, im on track for creating a chat system with the "fewest moving parts". im hope you will agree this is true p2p and i hope i can use this as a step towards true privacy and security. security might be further improved by using a trusted VPN.
i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work.
i created a decentralized todo list demo using the p2p framework used in the chat app. this is to demonstrate the bare-minimum functionality of decentralised messaging and state management.
while there are several similar apps out there like mine. i think mine is distinctly a different approach so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.
P2P Messaging and State Management: Todo List Demo.
P2P framework. Contribute to positive-intentions/p2p development by creating an account on GitHub.
a decentralized P2P todo list app to to demo the P2P framework used in the chat app.
https://github.com/positive-intentions/chat
This is a wrapper around peerjs. peerjs is good, but it can become complicated to use on complicated projects. This implementation is an attempt to create something like a framework/guideline for decentralized messaging and state management.
https://positive-intentions.github.io/p2p/?path=/story/demo-todo-list--basic
how it works:
- crypto-random ids are generated and used to connect to peerjs-server (to broker a webrtc connection)
- peer1 shares this ID to another browser/tab/person (use the storybook props)
- peers are then automatically connected.
- add todo item
- edit todo item
There are several things here to improve like:
- general cleanup throughout (its early stage for this project and missing all the nice things like good-code and unit-tests)
- adding extra encryption keys for messages comming in and going out (webrtc mandates encryption already)
- handling message callbacks
- key rotation
The goal is to create a private and secure messaging library in JavaScript running in a browser.
It depends on how and what you use it for.
WebRTC shares details like ip addresses and if you don't want those exposed, you shouldn't use this app. This app is aiming to use true P2P as a step towards true privacy and security.
The app is far from finished.
I'm not sure about what you're asking. Maybe it's about getting started? https://youtu.be/KKpu2rXvqfM?si=iWyTv9PzSpcAnsmr
What does “authentication” mean if there’s no server? - the app uses browser based cryptography functions as described here: https://github.com/positive-intentions/cryptography/blob/staging/src/stories/components/Cryptography.tsx .... basically asymmetric and symmetric keys are generated between peers on the initial connection and stored on device (indexedDB). maybe this helps: https://positive-intentions.com/docs/research/authentication/
How do browsers behind NAT connect to each other? - the app is using peerjs and so it also uses the peerjs-server as a connection broker. im investigating things like exchanging webrtc connection data offline with things like qr-codes.
How does it verify that the other chat partner is who they say they are? - the asymmetric keys exchanged after the initial connections. i cant drive home a point more clearly. the first connection should be secure, the peerID is cryptographically random, but i have to defer the responsibility of exchanging this ID to a peer they trust. https://positive-intentions.com/docs/basics/getting-started#security-reminders
Why use this and not Simplex? - this app is a work in progress and not ready to replace anything.
this is a side project and im unable set anything aside for having security professionals take a look. its important to note, i am not a cryptography expert... i just know enough to create the app. i try to make this clear in all of my posts that it is for testing purposes only because it could be irresponsible to advertise this this fully working. while the security attempt is genuine. to fix various issues throught the app, i expect there will be breaking changes.
further more about security assessment; while the app is open source, i found that its too complicated for a security assessment without a budget. this is going to be addressed in a ground up implementation of the p2p framework. https://github.com/positive-intentions/p2p ... this will eventually replace what is being used in the app and will make it easier to inspect how it works.
thanks for the feedback!
the app is a work in progress and full of bugs and issues. as a side project i can only set aside so much time to do things. the app as you see it is something im approaching with a "release often" approach. this will highlight thing like you are doing for me to prioritize. the profile loading from file is something i havent taken a look at in a while so thanks for that! i will take a look when i can make time for it :)
the cryptography in the app can be a whole separate discussion. but to be brief, the crypto signature input is something the app uses to generate a cryptographically random value... basically whatever you draw (e.g. "a smiley face") gets converted to a base64 string... then this is passed through a sha-256 hashing function. the idea is that even if you try, you could never draw the "exact" same smiley that would be pixel perfect and result in the same hash. the app also appends this to the cryptographically random value generated from the browsers built-in functions. so that crypto-signature is actually entirely redundent but could address concerns about the device/browser cryptography functions being compromized.
for the QR, i tried to make it a resolution that would be reasonable to view from another phone... to see the data that is being squashed into the QR codes for offline, you can take a look at the details around here. https://github.com/positive-intentions/chat/issues/6 ... there is an offline demo described there where instead of QR code it shows the data as plain text (this will include things like IP so you shouldnt be pasting this publicly anywhere... these details generated only exist on your device in memory)
Matrix is a good implementation and I like how it works. Mine is a work in progress and far from finished. It isn't ready to replace any app or service. The key detail about my app is that it's browser based. This has its own limitations with what a webapp can do. I think it makes for a different approach to decentralized chat.
Encrypted P2P Chat
chat.positive-intentions.com
https://github.com/positive-intentions/chat
I'm excited to share with you an instant messaging application I've been working on that might interest you. This is a chat app designed to work within your browser, with a focus on browser-based security and decentralization.
What makes this app unique is that it doesn't rely on messaging servers to function. Instead, it works based on your browser's javascript capabilities, so even low-end devices should work.
Here are some features of the app:
- Encrypted messaging: Your messages are encrypted, making them more secure.
- File sharing: Easily share files using WebRTC technology and QR codes.
- Voice and video calls: Connect with others through voice and video calls.
- Shared virtual space: Explore a shared mixed-reality space.
- Image board: Browse and share images in a scrollable format.
Your security is a top priority. Here's how the app keeps you safe:
- Decentralized authentication: No central server is required for login, making it harder for anyone to gain unauthorized access.
- Unique IDs: Your ID is cryptographically random, adding an extra layer of security.
- End-to-end encryption: Your messages are encrypted from your device to the recipient's device, ensuring only you and the recipient can read them.
- Local data storage: Your data is stored only on your device, not on any external servers.
- Self-hostable: You have the option to host the app on your own server if you prefer.
The app is still in the early stages and I'm exploring what's possible with this technology. I'd love to hear your feedback on the idea and the current state of the app. If you have any feature requests or ideas, I'm all ears in the comments below!
Looking forward to hearing your thoughts!