xoron

joined 2 years ago
[–] xoron@programming.dev 1 points 2 weeks ago

threat model

It's client side JavaScript. I think a webrtc connections is reasonably audited and encrypted. When using webrtc, ip addresses have to be shared. If the IP address could be hidden, it would improve "privacy" on my app.

It would be ideal if I could find a way to interface with the tor network with Client-Side JavaScript. I've come across something interesting here which id like to investigate further. https://github.com/Ayms/node-Tor

 

I wanted to investigate about onion routing when using WebRTC.

Im using PeerJS in my app. It allows peers to use any crypto-random string to connect to the peerjs-server (the connection broker). To improve NAT traversal, im using metered.ca TURN servers, which also helps to reduce IP leaking, you can use your own api key which can enable a relay-mode for a fully proxied connection.

For onion routing, i guess i need more nodes, which is tricky given in a p2p connection, messages cant be sent when the peer is offline.

I came across Trystero and it supports multiple strategies. In particular i see the default strategy is Nostr... This could be better for secure signalling, but in the end, the webrtc connection is working correctly by aiming for fewer nodes between peers - so that isnt onion routing.

SimpleX-chat seems to have something it calls 2-hop-onion-message-routing. This seems to rely on some managed SMP servers. This is different to my current architecture, but this could ba a reasonable approach.


In a WebRTC connection, would there be a benefit to onion routing?

It seems to require more infrastructure and network traffic... and can no longer be considered a P2P connection. The tradeoff might be anonymity. Maybe "anonymity" cannot be possible in a WebRTC connection.

Can the general advice here be to "use a trusted VPN"?

 

I wanted to investigate about onion routing when using WebRTC.

Im using PeerJS in my app. It allows peers to use any crypto-random string to connect to the peerjs-server (the connection broker). To improve NAT traversal, im using metered.ca TURN servers, which also helps to reduce IP leaking, you can use your own api key which can enable a relay-mode for a fully proxied connection.

For onion routing, i guess i need more nodes, which is tricky given in a p2p connection, messages cant be sent when the peer is offline.

I came across Trystero and it supports multiple strategies. In particular i see the default strategy is Nostr... This could be better for secure signalling, but in the end, the webrtc connection is working correctly by aiming for fewer nodes between peers - so that isnt onion routing.

SimpleX-chat seems to have something it calls 2-hop-onion-message-routing. This seems to rely on some managed SMP servers. This is different to my current architecture, but this could ba a reasonable approach.


In a WebRTC connection, would there be a benefit to onion routing?

It seems to require more infrastructure and network traffic... and can no longer be considered a P2P connection. The tradeoff might be anonymity. Maybe "anonymity" cannot be possible in a WebRTC connection.

Can the general advice here be to "use a trusted VPN"?

[–] xoron@programming.dev 4 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

the org can be found here: https://github.com/positive-intentions

the prerelease demo linked in the post is not open source.

[–] xoron@programming.dev 1 points 3 weeks ago (1 children)

do you perhaps have something running on localhost at those ports? i was trying something out, but i will disable it so it doesnt have this issue when users try to selfhost themselves.

it isnt well explained or demonstrated, but i was trying to do something as described in the link below, where i could connect a selfhosted federated module and have it work as a drop-in replacement.

https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure

the purpose was to see if there is any benefit to allowing users to host their own federated modules. i think there isnt a distinct advantage so it looks like i will remove that feature entirely.

[–] xoron@programming.dev 1 points 3 weeks ago

im still think of a better name for the project before i promote it properly as stable and secure. "positive-intentions" is understandably not well recieved.

i call it a "whatsapp clone" to better describe what it can be used for. this is in contrast to calling it a "p2p instant messaging app"... that just sounds too verbose.

[–] xoron@programming.dev 2 points 3 weeks ago* (last edited 3 weeks ago) (3 children)

thanks for letting me know, i'll take a look.

edit: perhaps this could be your issue... consider that your user-ID is the same one used when you reload the page or open it on another tab. if you open a new browser tab, it will try to connect to the peerjs server with an ID thats already in use... instead try with one incognito browser window (or a separate device).

-2
P2P WhatsApp Clone (infosec.pub)
submitted 3 weeks ago* (last edited 3 weeks ago) by xoron@programming.dev to c/privacy@programming.dev
 

Want to send E2E encrypted messages and video calls with no downloads, no sign-ups and no tracking?

This prototype uses PeerJS to establish a secure browser-to-browser connection. Using browser-only storage—true zerodata privacy!

Check out the pre-release demo here.

NOTE: This is still a work-in-progress and partially a close-source project. To view the open source version see here. It has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app.


How it works:

PeerJS allows users to connect with a unique string. A crypto-random ID is generated automatically on the frontend and used for the connection.

To connect, you can share your unique ID. Strangers are not able to guess your ID. Upon the initial connection, new encryption keys are exchanged and persisted to browser storage. These are used to encrypt message payloads to be sent over the WebRTC connection as created with PeerJS.

After a page reload (or future session), the app automatically pings the "known peers". If connecting to to a peer ID that is already registered, the previsously establish encryption keys are used to authenticate the user. This helps prevent MITM.

3
P2P Whatsapp Clone (infosec.pub)
submitted 1 month ago* (last edited 1 month ago) by xoron@programming.dev to c/securecoms@programming.dev
 

Want to send E2E encrypted messages and video calls with no downloads, no sign-ups and no tracking?

This prototype uses webRTC to establish a secure browser-to-browser connection. Everything is ephemeral and cleared when you refresh the page—true zerodata privacy!

Check out the pre-release demo here.

NOTE: This is still a work-in-progress and a close-source project. Its far from finished and doesnt have the user-experience needed to promote the project to a wider audience. The implementation is based on the open source MVP seen here. It has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app.

[–] xoron@programming.dev 3 points 1 month ago* (last edited 1 month ago)

thanks. this implementation is intended for a p2p messaging app. it works as a webapp and only stores data locally.

the signal architecture requires prekeys to be store on a server, in a p2p approach you dont need presigned keys and the double rachet starts immidiately (the tradoff is there is no offline messaging).

im investigating making it so that the service worker caches the initial static files... so page-refreshes dont update the loaded statics. there would be an explicit button to update the statics for the service worker. i have a basic concept working but it isnt finished enough for me to roll-out.

when open-source, there are additional capabilities that can be unlocked like being able to run the app from index.html without a static server. this would be stronger against anyone making changes on the network-level.

i understand why signal doesnt do a webapp like many other sevices like whatsapp... the p2p messaging architecture is fundamentally different.

 

making this post hidden because it doesnt seem well recieved. maybe its the wrong community for the feedback im after.

sorry.


TLDR; for my project i wanted the signal protocol that would work in a browser. i couldnt find something suitable... so empowered by AI, i tried to create something myself. i dont want to inspire undue confidence.

IMPORTANT: this project is not professionally audited or production ready.


for my p2p messaging project (a webapp) i wanted to explore an usage of the Signal protocol.... the investigation is still in progress and far from finished. its clear that the Signal protocol is not intended for a p2p architecture with it needing things like pre-keys stored on servers. so it seems nessesary to adapt it.

i looked around for a suitable implementation i could use. compiling the implementation in lib-signal-go to a wasm seemed like an option that worked... i was concerned about it seeming unmaintained and not mention of an audit. perhaps naive, but i decided to see if it could put something together. i started off creating something using browser-based cryptograpy primitives. i would have like to keep it that way, but an ealier AI audit disagreed to using those primitives and so i moved towards an attempt in rust that compiles to wasm.

https://github.com/positive-intentions/cryptography/tree/staging/src/rust

i added several unit tests and and got AI to try create better securty audits, and i think its working well. (or at least well enough). AI's security audit points me to many things i can improve throughout (so i will when i can).

this is fairly complicated stuff and i know better than to ask people to spend their own time to review my experimental project... im not sharing for you to review my code; im sharing this here if this is interesting for anyone to take a look.


(note: the repo is getting a bit too "full" and i will be splitting it into a separate repo for just the signal implementation.)

(note 2: im aiming for it to be aligned to the correct spec. im completely aware about concerns around using AI in the domain of cybersec. its great to have an opinion on the matter, but its not a fruitful conversation to be shocked that "AI is being used in 2025". the source and audit are provided for transparency. if there is something wrong with the details, thats what i want to discuss and fix.)

[–] xoron@programming.dev 1 points 1 month ago

Not ideal, but a professional audit is not an option.

To be clear, my prompt was not "create me a security audit". it took time and effort with several stages of refinement. I suspect more effort than writing that article.

It's open source for you to critique in a more involved way. The AI audit is intended to get to there faster. If you see any details that are wrong, I'll be happy to take a look and update appropriately.

 

TLDR; for my project i wanted the signal protocol that would work in a browser. following a previous post i made about looking for the signal protocol in javascript, i couldnt find something suitable... so empowered by AI, i tried to create something myself. i dont want to inspire undue confidence.

IMPORTANT: this project is not professionally audited or production ready.


for my p2p messaging project (a webapp) i wanted to explore an usage of the Signal protocol.... the investigation is still in progress and far from finished. its clear that the Signal protocol is not intended for a p2p architecture with it needing things like pre-keys stored on servers. so it seems nessesary to adapt it.

i looked around for a suitable implementation i could use. compiling the implementation in lib-signal-go to a wasm seemed like an option that worked... but given AI is everywhere, i decided to see if it could put something better together. i started off creating something using browser-based cryptograpy primitives. i would have like to keep it that way, but an ealier AI audit disagreed to using those primitives and so here is an attempt in rust that compiles to wasm.

https://github.com/positive-intentions/cryptography/tree/staging/src/rust

i added several unit tests and and got AI to try create better securty audits, and i think its working well. (or at least well enough). AI's security audit points me to many things i can improve throughout (so i will when i can).

this is fairly complicated stuff and i know better than to ask people to spend their own time to review my experimental project... im not sharing for you to review my code; im sharing this here if this is interesting for anyone to take a look.


(note: the repo is getting a bit too "full" and i will be splitting it into a separate repo for just the signal implementation.)

 

TLDR; for my project i wanted the signal protocol that would work in a browser. following a previous post i made about looking for the signal protocol in javascript, i couldnt find something suitable... so empowered by AI, i tried to create something myself. i dont want to inspire undue confidence.

IMPORTANT: this project is not professionally audited or production ready.


for my p2p messaging project (a webapp) i wanted to explore an usage of the Signal protocol.... the investigation is still in progress and far from finished. its clear that the Signal protocol is not intended for a p2p architecture with it needing things like pre-keys stored on servers. so it seems nessesary to adapt it.

i looked around for a suitable implementation i could use. compiling the implementation in lib-signal-go to a wasm seemed like an option that worked... but given AI is everywhere, i decided to see if it could put something better together. i started off creating something using browser-based cryptograpy primitives. i would have like to keep it that way, but an ealier AI audit disagreed to using those primitives and so here is an attempt in rust that compiles to wasm.

https://github.com/positive-intentions/cryptography/tree/staging/src/rust

i added several unit tests and and got AI to try create better securty audits, and i think its working well. (or at least well enough). AI's security audit points me to many things i can improve throughout (so i will when i can).

this is fairly complicated stuff and i know better than to ask people to spend their own time to review my experimental project... im not sharing for you to review my code; im sharing this here if this is interesting for anyone to take a look.


(note: the repo is getting a bit too "full" and i will be splitting it into a separate repo for just the signal implementation.)

[–] xoron@programming.dev 2 points 1 month ago* (last edited 1 month ago)

that sounds like a good idea to explore. i didnt consider nostr, but i think i can fit it in. my implementation is fairly unique because im trying out an application-level cascading cipher. the following article isnt finished, but might show some insights.

https://positive-intentions.com/blog/cascading-cipher-encryption

like with the signal-protocol, it should be possible to adapt the nostr-protocol to be able to daisy chain to the cascade. im already using the MLS protocol in the cascade to help manage group messages. after taking a quick look at the nostr-protocol. i think its a good idea how it handles relaying messages. it could be useful for group messaging.

 

TLDR; for my project i wanted the signal protocol that would work in a browser. following a previous post i made about looking for the signal protocol in javascript, i couldnt find something suitable... so empowered by AI, i tried to create something myself. i dont want to inspire undue confidence.

IMPORTANT: this project is not professionally audited or production ready.


for my p2p messaging project (a webapp) i wanted to explore an usage of the Signal protocol.... the investigation is still in progress and far from finished. its clear that the Signal protocol is not intended for a p2p architecture with it needing things like pre-keys stored on servers. so it seems nessesary to adapt it.

i looked around for a suitable implementation i could use. compiling the implementation in lib-signal-go to a wasm seemed like an option that worked... but given AI is everywhere, i decided to see if it could put something better together. i started off creating something using browser-based cryptograpy primitives. i would have like to keep it that way, but an ealier AI audit disagreed to using those primitives and so here is an attempt in rust that compiles to wasm.

https://github.com/positive-intentions/cryptography/tree/staging/src/rust

i added several unit tests and and got AI to try create better securty audits, and i think its working well. (or at least well enough). AI's security audit points me to many things i can improve throughout (so i will when i can).

this is fairly complicated stuff and i know better than to ask people to spend their own time to review my experimental project... im not sharing for you to review my code; im sharing this here if this is interesting for anyone to take a look.


(note: the repo is getting a bit too "full" and i will be splitting it into a separate repo for just the signal implementation.)

 

I've been exploring a cryptographic concept I can't find an existing name for, and I'd appreciate the community's insight. While I suspect it's overly redundant or computationally heavy, initial testing suggests performance isn't immediately crippling. I'm keen to know if I'm missing a fundamental security or design principle.

The Core Concept

Imagine nesting established, audited cryptographic protocols (like Signal Protocol and MLS) inside one another, not just for transport, but for recursive key establishment.

  1. Layer 1 (Outer): Establish an encrypted channel using Protocol A (e.g., Signal Protocol) for transport security.
  2. Layer 2 (Inner): Within the secure channel established by Protocol A, exchange keys and establish a session using a second, distinct Protocol B (e.g., MLS).
  3. Layer 3 (Deeper): Within the secure channel established by Protocol B, exchange keys and establish a third session using a deeper instance of Protocol A (or a third protocol).

This creates an "encryption stack."

Key Exchange and Payload Encryption

  • Key Exchange: Key material for a deeper layer is always transmitted encrypted by the immediate outer layer. A round-robin approach could even be used, where keys are exchanged multiple times, each time encrypted by the other keys in the stack, though this adds complexity.
  • Payload Encryption: When sending a message, the payload would be encrypted sequentially by every layer in the stack, from the deepest inner layer (Layer N) out to the outermost layer (Layer 1).

Authenticity & Verification

To mitigate Man-in-the-Middle (MITM) attacks and ensure consistency across the layers, users could share a hash computed over all the derived public keys/session secrets from each established layer. Verifying this single combined hash would validate the entire recursive key establishment process.

The Question for the Community

Given that modern protocols like Signal and MLS are already robustly designed and audited:

  1. Are there existing cryptographic terms for this concept of recursively nesting key exchanges? Is this a known (and perhaps discarded) pattern?
  2. What are the fundamental security trade-offs? Does this genuinely add a measurable security margin (e.g., against a massive quantum break on one algorithm but not the other) or is it just security theater due to the principle of "more is not necessarily better"?
  3. What are the practical and theoretical cons I may be overlooking, beyond computational overhead and complexity? Is there a risk of creating cascading failure if one layer is compromised?

I'm prototyping this idea, and while the overhead seems tolerable so far, I'd appreciate your technical critique before considering any real-world deployment.


my wording before AI transcription:

i dont know how to describe it more elegantly. i hope the title doesnt trigger you.

i was thinking about a concept and i couldnt find anything online that matched my description.

im sure AI is able to implement this concept, but i dont see it used in other places. maybe its just computationally heavy and so considered bad-practice. its clearly quite redundent... but id like to share. i hope you can highlight anything im overlooking.

in something like the Signal-protocol, you have an encrypted connection to the server as well as an additional layer of encryption for e2e encryption... what if we used that signal-protocol encrypted channel, to then exchange MLS encryption keys... an encryption protocol within an encryption protocol.

... then, from within the MLS encrypted channel, establish an additional set of keys for use in a deeper layer of the signal protocol. this second layer is redundent.

you could run through the "encryption stack" twice over for something like a round-robin approach so each key enchange has been encrypted by the other keys. when encrypting a payload you would be encrypting it it in order of the encryption-stack

for authenticity (avoiding MITM), users can share a hash of all the shared public keys so it can verify that the encryption key hashes match to be sure that each layer of encryption is valid.

this could be very complicated to pull off and unnessesary considering things like the signal, mls, webrtc encryption should already be sufficiently audited.

what could be the pros and cons to do this?... im testing things out (just demo code) and the performance doesnt seem bad. if i can make the ux seamless, then i would consider rolling it out.


same question on reddit (has some responses): https://www.reddit.com/r/crypto/comments/1oi4xqt/multiprotocol_cascading_roundrobin_cipher

 

I've been exploring a cryptographic concept I can't find an existing name for, and I'd appreciate the community's insight. While I suspect it's overly redundant or computationally heavy, initial testing suggests performance isn't immediately crippling. I'm keen to know if I'm missing a fundamental security or design principle.

The Core Concept

Imagine nesting established, audited cryptographic protocols (like Signal Protocol and MLS) inside one another, not just for transport, but for recursive key establishment.

  1. Layer 1 (Outer): Establish an encrypted channel using Protocol A (e.g., Signal Protocol) for transport security.
  2. Layer 2 (Inner): Within the secure channel established by Protocol A, exchange keys and establish a session using a second, distinct Protocol B (e.g., MLS).
  3. Layer 3 (Deeper): Within the secure channel established by Protocol B, exchange keys and establish a third session using a deeper instance of Protocol A (or a third protocol).

This creates an "encryption stack."

Key Exchange and Payload Encryption

  • Key Exchange: Key material for a deeper layer is always transmitted encrypted by the immediate outer layer. A round-robin approach could even be used, where keys are exchanged multiple times, each time encrypted by the other keys in the stack, though this adds complexity.
  • Payload Encryption: When sending a message, the payload would be encrypted sequentially by every layer in the stack, from the deepest inner layer (Layer N) out to the outermost layer (Layer 1).

Authenticity & Verification

To mitigate Man-in-the-Middle (MITM) attacks and ensure consistency across the layers, users could share a hash computed over all the derived public keys/session secrets from each established layer. Verifying this single combined hash would validate the entire recursive key establishment process.

The Question for the Community

Given that modern protocols like Signal and MLS are already robustly designed and audited:

  1. Are there existing cryptographic terms for this concept of recursively nesting key exchanges? Is this a known (and perhaps discarded) pattern?
  2. What are the fundamental security trade-offs? Does this genuinely add a measurable security margin (e.g., against a massive quantum break on one algorithm but not the other) or is it just security theater due to the principle of "more is not necessarily better"?
  3. What are the practical and theoretical cons I may be overlooking, beyond computational overhead and complexity? Is there a risk of creating cascading failure if one layer is compromised?

I'm prototyping this idea, and while the overhead seems tolerable so far, I'd appreciate your technical critique before considering any real-world deployment.


my wording before AI transcription:

i dont know how to describe it more elegantly. i hope the title doesnt trigger you.

i was thinking about a concept and i couldnt find anything online that matched my description.

im sure AI is able to implement this concept, but i dont see it used in other places. maybe its just computationally heavy and so considered bad-practice. its clearly quite redundent... but id like to share. i hope you can highlight anything im overlooking.

in something like the Signal-protocol, you have an encrypted connection to the server as well as an additional layer of encryption for e2e encryption... what if we used that signal-protocol encrypted channel, to then exchange MLS encryption keys... an encryption protocol within an encryption protocol.

... then, from within the MLS encrypted channel, establish an additional set of keys for use in a deeper layer of the signal protocol. this second layer is redundent.

you could run through the "encryption stack" twice over for something like a round-robin approach so each key enchange has been encrypted by the other keys. when encrypting a payload you would be encrypting it it in order of the encryption-stack

for authenticity (avoiding MITM), users can share a hash of all the shared public keys so it can verify that the encryption key hashes match to be sure that each layer of encryption is valid.

this could be very complicated to pull off and unnessesary considering things like the signal, mls, webrtc encryption should already be sufficiently audited.

what could be the pros and cons to do this?... im testing things out (just demo code) and the performance doesnt seem bad. if i can make the ux seamless, then i would consider rolling it out.


same question on reddit (has some responses): https://www.reddit.com/r/crypto/comments/1oi4xqt/multiprotocol_cascading_roundrobin_cipher

 

IMPORTANT NOTE - READ FIRST:

NONE of my projects have been audited or reviewed. I provide them for testing and demo purposes only. NOT to replace any other app you use.

BE RESPONSIBLE WHEN USING UNAUDITED SOFTWARE… DO NOT USE FOR SENSITIVE PURPOSES.


Now that I’ve hit you over the head with caution…

Want to send encrypted WebRTC messages and video calls with no downloads, no sign-ups and no tracking?

This prototype uses WebRTC to establish an encrypted browser-to-browser connection. Everything is stored locally in browser storage and cleared when you clear the site data from your browser - true zerodata privacy!

[–] xoron@programming.dev 1 points 2 months ago (1 children)

youre right that embarrassment is no reason to not open source it. i simply am investigating a close source direction to create a competative product.

if you interested in how this mechanics work, a very complicated version of it can be seen in: https://github.com/positive-intentions/chat (maybe you can get some AI on it.) ... the p2p call demo is a module im creating to be refinement of the old p2p functionality.

im aware that security and privacy doesnt easily fit with close-source, so id like to eventually open source it when i can figure out funding. open source from the onset didnt work out how i naively thought it would in the old version.

[–] xoron@programming.dev 2 points 2 months ago

thanks.

thats unfortunate it doesnt work. maybe a direct link to the storybook can help: https://p2p.positive-intentions.com/?path=%2Fstory%2Fdemo-p2p-call--video-call

i didnt clarify... the glitr app is a ui with hard-coded dara. the functionality in this p2p calls demo is what would be integrated into that ui. its far from finished and doesnt really "work"

my code and documentation website needs much more work before i can point to it for clarity. but i open sourced the poc version here: https://github.com/positive-intentions/chat ... you may see that the UI isnt very unintuitive to use and why im going in a different direction with the UI.

[–] xoron@programming.dev 2 points 2 months ago (2 children)

pardon for copying from another reply...

i agree. they are all better and more secure when selfhosted.

my project so far is an early preview into the p2p framework in my project. with feedback i can improve the functionality as i integrate it into my messaging app.

https://glitr.positive-intentions.com/

[–] xoron@programming.dev 2 points 2 months ago

these are good points. with peerjs this is easily configurable.

can i pick your brain about a config like the following:

const newPeer = new Peer(`blah`, {
        config: {
          iceServers: [
            { url: "stun:stun.l.google.com:19302" },
            { url: "stun:stun1.l.google.com:19302" },
            { url: "stun:stun2.l.google.com:19302" },
            { url: "stun:stun3.l.google.com:19302" },
            { url: "stun:stun4.l.google.com:19302" },
          ],
        },
      });

perhaps you would prefer to manually set your own config there with input fields?

id appriciate any insights into what you think users with that particular issue would like or find useful.

3
submitted 2 months ago* (last edited 2 months ago) by xoron@programming.dev to c/privacy@programming.dev
 

Want encrypted WebRTC video calls with no downloads, no sign-ups, and no tracking?

This prototype uses PeerJS to establish a secure browser-to-browser connection. Everything is ephemeral and cleared when you refresh the page—true zero data privacy!

Check out the demo: https://p2p.positive-intentions.com/iframe.html?globals=&args=&id=demo-p2p-call--video-call&viewMode=story


NOTE: This is a close-source project and has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app.

view more: next ›