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. I have open source examples of various part of the app and im sure more investigation needs to be done for all details of this project. USE RESPONSIBLY!

Im aiming to create the "theoretically" most secure messaging app. This has to be entirely theoretical because its impossible to create the "most secure messaging app". Cyber-security is a constantly evolving field and no system can be completely secure.

If you'd humor me, i tried to create an exhaustive list of features and practices that could help make my messaging app as secure as possible. Id like to open it up to scrutiny.

Demo

(Im grouping into green, orange and red because i coudnt think of a more appropriate title for the grouping.)

Green

• P2P - so that it can be decentralized and not rely on a central server for exchanging messages. The project is using WebRTC to establish a p2p connection between browsers.
• End to end encryption - so that even if the messages are intercepted, they cannot be read. The project is using an application-level cascading cipher on top of the encryption provided by WebRTC. the key sub-protocols involves in the approach are Signal, MLS and AES. while there has been pushback on the cascading cipher, rest-assured that this is functioning on and application-level and the purpose of the cipher is that it guarantees that the "stronger" algoritm comes up on top. any failure will result in a cascading failure... ultimately redundent on top of the mandated WebRTC encryption. i would plan to add more protocols into this cascade to investigate post-quantum solutions.
• Perfect forward secrecy - so that if a key is compromised, past messages cannot be decrypted. WebRTC already provides a reasonable support for this in firefox. but the signal and mls protocol in the cascading cipher also contribute resiliance in this regard.
• Key management - so that users can manage their own keys and not rely on a central authority. there is key focus on having local-only encryption keys. sets of keys are generated for each new connection and resued in future sessions.
• Secure signaling - so that the initial connection between peers is established securely. there are many approaches to secure signaling and while a good approach could be exchanging connection data offline, i would also be further improving this by providing more options. its possible to establish a webrtc connection without a connection-broker like this.
• Minimal infrastructure - so that there are fewer points of failure and attack. in the Webrtc approach, messages can be sent without the need of a central server and would also work in an offline hotspot network.
• Support multimedia - so that users can share animations and videos. this is important to provide an experience to users that makes the project appraling. there is progress made on the ui component library to provide various features and functionality users expect in a messaging app.
• Minimize metadata - so no one knows who’s messaging who or when. i think the metadata is faily minimal, but ultimately is reletive to how feature-rich i want the application. things like notification that a "user is typing" can be disabled, but its a common offering in normal messaging apps. similarly i things read-reciepts can be a useful feature but comes with metadata overhead. i hope to discuss these feature more in the future and ultimately provide the ability to disable this.

Orange

• Open source - moving towards a hybrid approach where relevent repositories are open source.
• Remove registration - creating a messaging app that eliminates the need for users to register is a feature that i think is desired in the cybersec space. the webapp approach seems to offer the capabilities and is working. as i move towards trying to figure out monetization, im unable to see how registration can be avoided.
• Encrypted storage - browser based cryptography is fairly capable and its possible to have important data like encryption keys encrypted at rest. this is working well when using passkeys to derive a password. this approach is still not complete because there will be improvements to take advantage of the filesystem API in order to have better persistence. passkeys wont be able to address this easily because they get cleared when you clear the site-data (and you lose the password for decrypting the data).
• User education - the app is faily technical and i could use a lot more time to provide better information to users. the current website has a lot of technical details... but i think its a mess if you want to find information. this needs to be improved.
• Offline messaging - p2p messaging has its limitations, but i have an idea in mind for addressing this, by being able to spin up a selfhosted version that will remain online and proxy messages to users when they come online. this is still in the early stages of development and is yet to be demonstrated.
• Self-destructing messages - this is a common offering from secure messaging apps. it should be relatively simple to provide and will be added as a feature "soon".
• Javascript - there is a lot of rhetiric against using javascript for a project like this because of conerns about it being served over the internet. this is undestandable, but i think concerns can be mitigated. i can provide a selfhostable static-bundle to avoid fetching statics from the intetnet. there is additional investigation towards using service workers to cache the nessesary files for offline. i would like to make an explicit button to "fetch latests statics". the functionality is working, but more nees to be done before rolling out this functionality.
• Decentralized profile: users will want to be able to continue conversations across devices. It's possible to implement a p2p solution for this. This is an ongoing investigation.

Red

• Regular security audits - this could be important so that vulnerabilities can be identified and fixed promptly. security audits are very expensive and until there is any funding, this wont be possible. a spicier alternative here is an in-house security audit. i have made attempts to create such audits for the signal protocols and MLS. im sure i can dive into more details, but ultimately an in-house audit in invalidated by any bias i might impart.
• Anonymity - so that users can communicate without revealing their identity is a feature many privacy-advocates want. p2p messages has nuanced trandoffs. id like to further investigate onion style routing, so that the origins can be hidden, but i also notice that webrtc is generally discourage when using the TOR network. it could help if users user a VPN, but that strays further from what i can offer as part of my app. this is an ongoing investigation.

Demo

FAQs:

Why are there closed source parts? - ive tried several grants applications and places that provide funding for open source project. im aware they exist… all rejected this project for funding. Im sure many are inundated with project submissions that have a more professional quality and able to articulate details better than myself. Continuing with open source only seems to put me at a competative disadvantage.

Monetization - Im investigating introducing clerk. I hope to use that to create a subscription model. I would like to charge $1 per-month as per the minimum allowed by clerk. I started off thinking i could avoid charging users entirely given it seems a norm for secure messaging apps to be free. but given the grant rejects and the lack of donations on github sponsors (completely understandable), but its clear that it wont be able to sustain the project. I tried Google adsense on the website/blog but it was making practically nothing; so i disabled it because it wasnt a good look when it goes against the whole “degoogling” angle. This project is currently not funded or monnetized in any way. (Its not for lack of trying)

How does it compare against signal, simpleX, element, etc? - The project is far from finished and it woudnt make sense to create something as clear as a comparison table. Especially because core features like group-messaging isnt working. Some technical details can be seen here if your want to draw your own comparison.

• https://positive-intentions.com/docs/projects/chat
• https://positive-intentions.com/docs/category/sparcle

Javascript over the internet is not secure - im investigating the to use service workers to cache the file. this is working to some degree, but needs improvement before i fully roll it out… i would like to aim for something like a button on the UI called “Update” that would invalidate the service-worker cache to trigger an update. I hope to have something more elegant than selfhosting on localhost or using a dedicated app. its possible to provide a static bundle that can work from running index.html in a browser without the need to run a static server. The static bundle of the open source version can be seen and tested to work from this directory: https://github.com/positive-intentions/chat/tree/staging/Frontend . When i reach a reasonable level of stability on the app, i would like to investigate things like a dedicated app as is possible on the open source version. https://positive-intentions.com/blog/docker-ios-android-desktop

How is this different to any other messaging app? - the key distinction between this project and other like it like simpleX is that its presented as a PWA. A key cybersecurity feature of this form-factor is that it can avoid installation and registration. its understandable that such a feature doesnt appeal to everyone, but along with the native build, it should cover all bases depending on your threat model.

What about Chat Control? - https://www.reddit.com/r/europrivacy/comments/1ndbkxn/help_me_understand_if_chatcontrol_could_affect_my

Aiming to provide industry grade security encapsulated into a standalone webapp. Feel free to reach out for clarity on any details or check out the following links:

• Docs: https://positive-intentions.com/
• Subreddit: https://www.reddit.com/r/positive//_intentions
• Mastodon: https://infosec.exchange/@xoron

IMPORTANT NOTE: It's worth repeating, this is still a work in progress and not ready to replace any existing solution. Provided for testing, demo and feedback purposes only.

This is very similar to the image encryption tool, except for audio.

Record or upload your audio message, decide the quality, encrypt and prepare for transport.

Source here

This is just another way to transform data that allows for the universal copy paste function. Transforming to base64 opens up more possibilities and compatibility for transport.

Use cases are limited but its nice to have the capability.

Server Manager

UI

Demo

This application is a local only web instance that can be spun up in termux.

Here is the source code.

Its configured to be a local only service utility although it wouldn't take much to point this to the web.

After picking a image, you can configure the compression. I found large image files basically require the compression. There is a limit to how much text you can copy...its very large...but the higher quality the image the longer this string of text will be, so you may need to lower the quality if you run into problems.

You can either copy the text directly, or download a blob as the .txt file for transport.

Termux side server manager.

Encrypted blob example.

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.

• Docs: https://positive-intentions.com/docs/category/sparcle
• Reddit: https://www.reddit.com/r/positive/_intentions
• Mastodon: https://infosec.exchange/@xoron
• More: https://positive-intentions.com/

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.

• Docs: https://positive-intentions.com/docs/category/sparcle
• Reddit: https://www.reddit.com/r/positive/_intentions
• Mastodon: https://infosec.exchange/@xoron
• More: https://positive-intentions.com/

A peer to peer private anonymous and secure messenger that works over tor. It's also free and open source software which gives users the freedom of changing it and redistributing it under the terms of the GNU General Public License v3.

Onion Courier is a production-ready anonymous communication system that implements a mixnet architecture over Tor hidden services. It provides strong anonymity guarantees against both local and global adversaries through cryptographic layered encryption, traffic analysis protection, and systematic cover traffic integration.

Another P2P hidden service for private messaging.

This is V1 of secure code book.

Features -Wordlist shuffling -Easy key generation -Additional key configs

Key Generator

Each of the over 58000 words is mapped to one unique arbitrary bit of information. This boolean logical circuit is the foundation of the encoding and decoding process.

This is one time pad. Used correctly, it's unbreakable.

Shannon contributed to the field of cryptanalysis for national defense of the United States during World War II, including his fundamental work on codebreaking and secure telecommunications, writing a paper which is considered one of the foundational pieces of modern cryptography,[15] with his work described as "a turning point, and marked the closure of classical cryptography and the beginning of modern cryptography".[16] His work was foundational for symmetric-key cryptography, including the work of Horst Feistel, the Data Encryption Standard (DES), and the Advanced Encryption Standard (AES).[16] As a result, Shannon has been called the "founding father of modern cryptography".

There are more ways to utilize OTP then to 2FA accounts.

Using an offline otp manager like andOTP you can generate time based codes derived from any shared secret. This can provide a whole new level of security in a scenario where Alice and Bob want to self verify a communication channel.

Broad Guide to Bootstrapping your own Codebook

Using a few key formulas you can create a functional code book with enormous keys that no computer could possibly brute force.

First let me explain how many possible keys there are in this particular example.

In this example the word list contains 3000 words. Each subsequent column labeled k1-k9 contains another 3000 bits of unique information. Each number of key columns added exponentially increases the total key possibilities.

In this schema the "Key" to encrypt and decrypt is the unique state of each cell in relation to the word list.

3000!^10 represents the amount of possibilities.

That is 2^91312 possible keys which makes aes 2^256 look completely wimpy.

Important Functions To Master To Build your Code Book

• randbetween()

-vlookup()

-ifs()

-concatenate()

All of these formulas can help automate the encode/decode process.

Ways to mitigate Frequency Analysis

-Layer the final ciphertext with other string encryption protocols.

-Increase the amount of key columns so that the encoding formula can pick a random column. This will allow the same word to be encoded multiple ways so that someone analyzing plaintext will hit a wall.

-Generate new keys. New keys can be generated by shuffling the key and wordlist columns. You can use sorting functions to randomize and shuffle the wordlist.

Ideal Operational Security

-Air gap the computers running the encoding/decoding processes

-Share the keyfiles offline

-Rotate keys often

-Destroying old keys

-Use already secured communication channels to add layers.

Final Notes

This is obviously not a convenient way to share a message. It requires dedicated hardware, and disciplined protection of the keyfiles to really be secure.

Regardless of what anyone tells you about the strength of modern encryption ciphers like AES256...do you really think a the most powerful nation in the world would release a unbreakable encryption protocol 15 days after 9/11? I don't think so pal

This is torch. A termux hosted hidden chat service.

Find it here After saving run with chmod +x torch.sh > ./torch.sh

Included features -PTT (if your browser supports it) -Lockdown mode. Adds E2EE -OTP mode. Generate time based keys to enhance security. -Voice changer -Add time stamp -Pin message to spam -File Sharing -Per room file organization -Delete server logs from web -Delete chat logs from web -Generate and spam random packets -Filter out generated noise (keep generating packets in background) -Optional per room cloudflared tunnels.

Here is the directory that is formed on startup.

Example server side chat logs with encryption enabled.

This is similar to Utopia, previously shared, with regard to functionality and peer-to-peer operation, but unlike Utopia this one is fully open source, is not blockchain based, and starts out with only connecting to your known friends. The devs are also known, and it uses well known PGP encryption which you share directly with your friend to get authenticated.

'Onion routing' is used for anonymity and needless to say you don't need your real-world credentials to register. Being P2P it does not require any servers or central services to operate - you connect to, and via, your friends directly, completely out of site of Big Tech.

It's a bit like your own private secure Facebook and is actually great for younger children to participate safely. There are no hidden costs, no ads and no terms of service. It installs on Windows, Linux and MacOS desktops, and on Android mobile. Sorry no iOS app.

See https://retroshare.cc/

#technology #P2P #decentralized #socialnetwork #privacy

Developer: @hereforawhile@lemmy.ml

Termux Torchat can be found here

This new version implements optional rotating time based keys, and a simple implentation of rachet forward secrecy.

Deploy secure world wide coms right from your own terminal or run the server on a old phone