Thanks!

I’d like to add data encryption at rest, but thats still a work in progress. A previous post on the matter: https://lemmy.ml/post/22209501 .

I hope to improve the project over time. A roadmap of possible capabilities can be seen here: https://positive-intentions.com/blog/introducing-decentralized-chat#roadmap-the-future-of-secure-file-sharing

I’m motivated to work on the project because its interesting, but it seems this project is not sustainable open source and so I’m investigating options in how to go forward.

(The chat app repository will still remain open source. Making it close-source would undermine it’s security claims.)

the web version is intended to work on all platforms without compilation.

a html file-input is simple to add on a webpage. when selecting a file, its loaded into memory. at that point you can encrypt that file and sent it over webrtc… voila; p2p encrypted file transfer.

my approach to a mobile (ios/android) version is using capacitorjs/tauri… its basically a native wrapper with a webview.

P2p encrypted file sharing is sadly still an unsolved problem

thanks for your input, but can you explain what you mean by “unsolved problem”?.. p2p encrypted file transfer is demonstrated in the app.

its browser based. it uses webrtc to create p2p connections between browsers. concepts like authentication takes the form of using cryptography capabilities of a typical browser. the storage of data from messages to encryption keys are stored in indexedDB as provided by the browser of your choice. there is an emphesis on client-side browser-based capabilities in all parts of the app.

matrix is a good peer reviewed and generally reccommended solution. this project isnt intended to replace any existing solution. there are many other similar projects out there, but i notice there arent many presented as webapps. this is my attempt.

My app is different because the auth is handled between peers. So it could only every be people you shared your ID with. Security is important for me on this project. Its more important than the app being popular. https://www.reddit.com/r/CyberSecurityAdvice/comments/1ev5kqn/is_this_a_secure_messaging_app/

People should not connect to strangers on this app because of the potential risks of IP exposure… But between people you trust or between your own devices, it should work as expected for testing.

As for allowing links with expiration, you basically have that already with what looks like the login/logout functionality. There is no actual registration, it’s just a UI for creating and deleting crypto random ID profiles.

Lemmy and the fediverse is a good idea. The federation makes it so I can see Lemmy posts on mastodon. Etc… id like to draw a parallel in my app with the chat-view and the inteagram-view

I don’t think this kind of app could be an alternative to instagram because of it only being P2P with only people you know.

The app is using webRTC which exposes IP addresses, so you wouldn’t want something like a global feed on this.

Immich sounds interesting. I’d like to make time to check it out.

https://positive-intentions.com/blog/p2p-social-media

Thanks!

P2P allows for a fairly unexplored infrastructure for content moderation. In this app, the feed of images would only be from people you connect to. For people to connect to you, you have to share a crypto random id.

As a webapp you can clear the site data by logging out. Basically, people cannot randomly connect to you and share things you don’t like.

I won’t be adding anything like a global feed. Only content that you shared or received.

This doesn’t remove the risk of people sending you things you don’t like so I’m all ears for an approach to that. I didn’t make much progress on the following. If there are any hard features you think would help, let me know. I’d like to make some time to create a “block contact” but it’ll take time and consideration to do it properly (so I don’t expect it soon). Things like logging out and being able to backup your profile might be enough, but not as user-friendly as it could be.

https://www.reddit.com/r/darknetplan/comments/16qw24o/on_my_decentralized_chat_app_i_want_some_kind_of/

Yes.

thanks! will delete.

Thanks. I’ve com across it before. You can find the corresponding security audit online.

Ive tried to address those concerns and I try to give details about it here: https://lemmy.ml/post/18497337

Thanks for the tip. WebRTC is using aes-128, I see in my code I’m using RSA. It sounds like a good idea like to create a cascading cypher with aes-256 which seems to be regarded as “military grade” (but it seems there is no official spec definition for this).

i added a section in the contact details page for validating public keys hash.

the experience could be improved in several ways with things like qrcodes, but for now, i think its a nice addition.

i will try set aside some time for proverif. im also investigating what is needed for CISA certification. even without the certification it’ll be interesting to see what i can do to security audit my own code (even though it looks like without and objective observer, the assessment isnt valid… but i could share it and someone else could say it looks good. and the overhead for them to assess my app could be less)

here are my thoughts on a possible approach.

it seems the concerns center around validating the keys.

solution 1 (generate new keys):

• i could add a functionality for regenerating keys.
• add functionality for exchanging the keys in various ways (qr, email, text, nfc)
• the remote peer app can import this file and update the contact’s keys.

solution 2 (validate keys):

• A generates hash of B’s public key
• A sends a link to B (through some trusted medium)
• link opens app validation page with the public key hash encoded in the url
• B generates hash of own public key (related to A)
• B is displayed “success response” if the hash is valid.
• (and vice-versa if wanted)

Spend some time trying to break your own system

i sure try, but im sure i’ve developed a bias about it being secure and so i might not be seeing all the possible scenarios. this is why feedback is important for me at this stage of development.

thanks for the link to that spec. it looks like it would be pretty unique between applications that have this type of spec. can you tell me what that kind of document is called?

i was recently pointed to something called ProVerif it seems to have a way of describing an implementation and it has some functionality to validate/detect security risks. ive only just come across it and and while it sounds too good to be true, it looks appropriately complicated. do you have any thought on it (or other tools like that)?

thanks!

i understand. can you help me understand what i can do for this. id appriciate if you could critique my approach:

im putting all the weight of the initial exchange being secure on the cryptographically random ID. if you can exchange that on a channel that is secure (whatsapp?/qr-code?/sms?), then the initial connection will establish the keys. the mitm there could be the peerjs-server (or even your ISP), but because the ID is crypto random, it would not be possible to predict who is who. (of course it could be logging connections and IP’s and figuring out from other metadata, but if that’s a concern, then you should selfhost a peerjs-server).

i previsously created something for sharing files by QR codes as described here. to enhance security more for when peers are together to exchange keys, ive taken that qr-code investigation further to create something that is able to transfer encryption keys fully offline.

a way for users to validate each others public keys

sorry for diving into the code here i dont expect you to start debugging my spaghetti code but to try and explain, let me point you to how i validate public keys. in the file found here around line 96 is what happens on an initial connection. it might not be clear, but i do something like:

• generate a crypto random hash locally
• send that to a peer (encrypted with their public key)
• the peer decrypts using they own private key
• they then send back that same random hash encrypted with my public key.
• decrypt using my private key

i would also like to make an update to check the that the keys are signed (not sure about the terminology, but it was suggested that is a better way to do this validation… will all the redundency i have going on, im not against doing both if its seamless to the user). (note: all peers get a new set of keys generated).

the app is basically a static bundle GUI for peerjs-server. by default it is using the officialy peerjs-server. this is to make it easier for users to get started. it is possible to host your own instance and configure to use it within the app. the frontend is decentralised in the sense it can be selfhosted. and data is only stored locally on your device on your browser. no registration database.

im also investigating options for establishing a webrtc connection with no backend using QR codes to exchange the connection data. this is working but not refined enough to roll out into the app. its something i want to address in the p2p microfrontend i mentioned earlier with the todo-list.

there is no federation with peerjs-server and so peers you connect to will have to be on the same server. for those cases you will have to connect to the same server which is why it makes sense to have a the official peerjs-server as the default. it is only used for brokering a webrtc connection after which connections are P2P.

Less code/complexity is less chance for bugs

completely agree. im breaking the app into smaller chunks (in the form of microfronends). i created a bare-minimum example of p2p communication and state management and framed it as a “todo list” app as can be seen here: https://p2p.positive-intentions.com/?path=/docs/demo-todo-list--docs . it doesnt have the bell and whistles of redundent browser cryptography. it isnt open source or anywhere near finished.

i am going in the direction of developing this further into basic chat functionality. the aim is that this new module will replace what is seen in the chat app. which i expect at that point will be a lot less complex than the one used in the app and with all the features like unit tests and documentation expected in quality work.

in the URL shared, that value is a cryptographically random value used as an ID for the peerjs-server. its best you dont share that publicly (like in your comment) because it undermines it being cryptographically random (the aim is to make it unguessable). i guess its like a phone number (i would suggest you clear all site data from your browser before continuing… you dont want strangers to connect.).

the way it works is that the unguessable ID is first used to connect peers. then on that initial connection, additional keys are created for the extra encryption. if in the future your ID is compromised people wont be able to impersonate you because messages to/from known-peers would be encrypted using that extra layer of encryption.

your feedback is appriciated. im not hurt at all i hope my tone doesnt suggest otherwise. i hope im not coming across an confrontational. i simply have answers and observations at this point which have developed from concerns ive heard before (yours included)… its the nature of learning and developing opinions.

i (perhaps naively) think have created a secure chat app and now it seems to be a matter of convincing others to gain traction. as you might be able to understand i have a bias on the implementation. it was unexpected for me to observe that open sourcing is worth less than paying for someone approval. going in that direction also means, every new PR would also needs to be security assessed.

while $50k can be ridiculous, ive been talking about my app long enough to know paying $1k will result in people questioning the quality of the review and could even work against me by being like i didnt spend anything at all. it seems like a false economy for a project like mine which i cant grow because i cant get funding.

open sourcing the project was done in the interest of the kerkhof-principle and would enable me to better ask for security audits from people who wanted to contribute to open source projects… but no luck. i think i made a reasonable attempt at asking and any more could be seen an spam (which could get me blocked from subreddits). https://www.reddit.com/user/Accurate-Screen8774/search/?q=audit&type=link&cId=4a3bc9d3-7b38-40da-a587-03b2f8ee65e5&iId=4d8c2619-3f64-4885-b360-cb804ddc7854

ultimately, i enjoy working on the project and have several ideas i want to try out so i will continue working on it with wording throughout about it being and “unstable experimental proof-of-concept” so as to not lead anyone to believe it is tried and tested by security professionals, which i think is an appropriate tradeoff.

Why are you adding an additional layer of complexity to webrtc? It has e2ee already?

the app is more “research + development” than “a product”. i started of with a webrtc chat app without the additional encryption and it worked like it does now. i wanted to explore some of the browser based functionalities for encryption and to my surprise, it seems fairly performant so i kept it in. it is a redundent layer of encryption and as long as it doesnt compromize the security or privacy, i dont see why not. similarly, im also investigating the cryptography capabilities from WASM.

How does a user validate that they are actually e2ee?

this is where the redundent layer of encryption shines. while webrtc has e2ee, using the browser crytography functions i can generate and exchange keys using the diffie-helman method and ensuring that the message can only be decrypted with the corresponding public-key. something i cant easily verify with webrtc, im just told that its there and it works.

Could a malicious server pretend to support your protocol and decrypt everything?

messages can only be decrypted using the public key exchanged after the initial connection (where those keys are generated and stored for future use). malicious actors will exist in any case and so while i think the app is secure for the majority of cases, here is a section where i have suggestions on enhacing your security. (hint: it relies of you being sensible with how you use the app and not connecting to people you dont trust.)