PrivateTalk – Encrypted & Self-Destructing Messages [100% Privacy | Open-Source]

[joker_josue]

 PrivateTalk - Encrypted & Self-Destructing Messages 
   [[100% Privacy | Encrypted | No database | No tracking | Open-Source]]
                                          [ Official Website ] | [ Official GitHub ]


I am pleased to introduce PrivateTalk, an open source project designed to send encrypted messages that self-destruct after being read, without the need for registration and with complete privacy.

After observing several projects for sending private self-destructing messages, which I felt did not really care about privacy, I decided to develop this project.

It was created with the community that values ​​anonymity, security and simplicity in mind, and is now available for free to everyone. Encrypted messages in the browser, which self-destruct after being read, without registration, without cookies, without hidden logs, without IP tracking, and without databases.


 What is PrivateTalk? 

• Tool for sending secure messages, encrypted in the browser itself.
• Messages self-destruct after being read or after a time period defined by the user.
• Does not require registration, does not store personal data, and does not use cookies.
• The code is open-source and can be audited by anyone.

 Features 

• Local encryption in the browser (AES-GCM)
• Single or split link for maximum privacy
• Optional extra password for enhanced protection
• Configurable auto-expiration and time-lock (“scheduled message”)
• Public destruction/expiration logs (mathematical proof)
• Local dashboard to manage your messages (without sending anything to the server)

 What does PrivateTalk do differently? 

100% local encryption:	Does encryption in the browser via AES-GCM, no message or key is sent to the server in clear text. Not even the administrator can access the content, even with full access to the server. Privnote: does not encrypt in the browser; the text goes to the server in clear text (although they say that “nobody reads it”, it is a matter of trust in the operator). One-Time Secret: offers encryption, but often the key is also on the server and security depends on the implementation. BurnNote/QuickForget: generally do not do client-side encryption; it is more of a “delete after read” approach.
Self-destruction and public logs:	After reading, the message is automatically and irreversibly destroyed. The system generates a unique SHA-256 hash of each message, publishing transparent destruction/expiration logs — anyone can verify that the file was deleted, no one can recover it. Others: Most do not show public logs or evidence of destruction. There is no transparency into what is deleted.
Advanced sharing:	Ability to split the secure link into two parts for maximum privacy — you can share the link and key across different channels, increasing privacy when using multiple channels. Others: Just provide a link, never suggest shard/key separation.
Time-lock and custom expiration:	Allows you to schedule the message to be read only between specific dates/times (e.g. only after 8pm and until 10pm), in addition to the traditional automatic expiration. Privnote/One-Time Secret: generally only support expiration after reading or fixed time.
No database, no tracking, no cookies:	Everything works with just flat files on the server. Zero tracking, zero analytics, zero external scripts. Not even analytics tools. Privnote: uses databases, can log accesses, usually has cookies and analytics scripts. Others: includes ads that can track users' browsing.
Private Dashboard:	Allows the user to monitor the status of their messages (read, active, expired) locally and manually, without sending sensitive information to third parties. Completely private, without automatic communication to the server. Others: Do not allow the user to manage the state of messages locally – only the server controls it.
Simple and auditable code:	Total focus on transparency, easy auditing, and maximum security for end users. Open-source, easy to follow, no obscure dependencies. Others: They are not open source, or have code that is very complex/difficult to audit.
No registrations, emails, SMS or Telegram:	It doesn't collect email, phone, or other user data, so there's no such notifications — more privacy, less tracking. Others: User for registering, providing email, telephone or other information to receive notifications, which may create a cross-referencing of information.

 FAQ 
How does it work?
   You type the message, the browser generates the encrypted link, and only those who have the link/key can read it. Once read or expired, it is impossible to recover.
Does the server see the messages?
   No. The text never leaves your browser in a readable format.
How does the Dashboard work?
   After creating the message, you can save it to a file on your computer with the link and a tag (link,tag) - one link per line. In the Dashboard, you load the file in the browser and it analyzes the logs to check the status of the message. The check is done in the browser, no file is ever sent to the server.


 Feedback, suggestions, or questions are welcome! 
Test it and leave your comment or contribute with ideas/bugs here in the topic (or on GitHub).
If you liked the project and want to support (or buy me a beer), I accept donations: bc1q9f2dhfdrzruyecfwea3n6nt2nuaj6htzgke5q2

Project inserted in the Talk2Tag project, which aims to present useful tools for forum users. I will give more information soon.

[joker_josue]

Reserved

[Satofan44]

Sounds good and interesting, but unfortunately without third party review it is a dangerous thing to use. I do not mean to offend in any way, but this is how users should approach these things. Countless "security" apps have been hacked or been honeypots in the last decade. I'm not that well versed with PHP, but I tried to take a look at what you are doing here to find some common pitfalls. Please keep in mind that all questions are questions of interest or ideas for improvement.

1. You use a random nonce for AES-GCM I think, are you checking somehow that they are never reused with the same key because that would be a disaster? If I remember correctly, even a single re-use would be a complete catastrophe!
2. Isn't 8 bytes of entropy a bit on the low end for the message ID? Why not add more?
3. How are you protecting against XSS attacks? Since everything happens in the browser, this is a big risk.

I'll have a better look soon, but you should get it reviewed somewhere.   Thanks for the answers.

[joker_josue]

1. You use a random nonce for AES-GCM I think, are you checking somehow that they are never reused with the same key because that would be a disaster? If I remember correctly, even a single re-use would be a complete catastrophe!
2. Isn't 8 bytes of entropy a bit on the low end for the message ID? Why not add more?
3. How are you protecting against XSS attacks? Since everything happens in the browser, this is a big risk.

I'll have a better look soon, but you should get it reviewed somewhere.   Thanks for the answers.

The project is open-source for that very reason, for anyone who wants to check out what was done and how it was done. If you detect any problems, share them so that they can be corrected. I am available to hear your opinions and analyses. 

Answering the questions raised:
1. A 12-byte random Nonce/IV generated by window.crypto.getRandomValues() is used whenever a message is encrypted. The encryption key is generated uniquely for each message (or derived directly from the user-supplied password/phrase, if extra protection is used). Each message/key combination is unique, with no reuse. Since there is no reuse of the key for multiple messages, the risk of catastrophe due to a duplicate Nonce/IV is virtually non-existent. Anyway, I can try to reinforce that guarantee.
2. The ID generated with 8 bytes (64 bits) of entropy already makes brute-force attacks difficult (there are 18.4 quintillion combinations). However, I recognize that increasing it to 128 bits (16 bytes) would be even more robust. In any case, the practical risk of collision with 8 bytes is extremely low, considering this initial aspect of the project. But I may adjust this.
3. I made it a priority to avoid any script execution or injected data. On the backend, PHP never returns the original message; only encrypted data. On the frontend, the message content is never inserted as HTML (only as plain text, via textContent). I will continue to monitor possible XSS vectors and if anyone finds any risks, let me know, I will try to resolve them immediately!

The goal of this project is to provide guarantees to the community that they can use it safely, so the code is open-source to facilitate community auditing.

[knowngunman]

I must commend your efforts for building this for the sake of privacy and the Bitcoin community.

I tested the site and it works fine but Here's my observation and suggestion.
The link attached for checking code in case of technical questions is not bringing out any result. I don't know if it is from my end or it is generally.


I'm not on PC right now. I use mobile to test run the site. Is it possible to disable Screenshot and screen recording features on the page? I'm not a tech guy and I don't know how this things works but I think that feature will add more privacy. Please put me through if I'm getting something wrong.

[joker_josue]

I'm not on PC right now. I use mobile to test run the site. Is it possible to disable Screenshot and screen recording features on the page? I'm not a tech guy and I don't know how this things works but I think that feature will add more privacy. Please put me through if I'm getting something wrong.

In fact there is a link on the site that I did not update correctly. Thanks for the warning, I will fix this soon

As for his suggestion, they had not thought of it. I'll look into the possibilities, thank you.

[Satofan44]

I must commend your efforts for building this for the sake of privacy and the Bitcoin community.

I tested the site and it works fine but Here's my observation and suggestion.
The link attached for checking code in case of technical questions is not bringing out any result. I don't know if it is from my end or it is generally.

You are right.
1. Directly from thread, it works. https://github.com/jokerjosue/PrivateTalk.
2. From the website, it also works. https://talk2tag.com/privatetalk/.
3. From the website, "Technical questions? Check the code." does not work. https://github.com/yourusername/PrivateTalk

Answering the questions raised:
1. A 12-byte random Nonce/IV generated by window.crypto.getRandomValues() is used whenever a message is encrypted. The encryption key is generated uniquely for each message (or derived directly from the user-supplied password/phrase, if extra protection is used). Each message/key combination is unique, with no reuse. Since there is no reuse of the key for multiple messages, the risk of catastrophe due to a duplicate Nonce/IV is virtually non-existent. Anyway, I can try to reinforce that guarantee.

In the short term, you are absolutely right. The chance of this happening is very low, but I am thinking about long term. If this tool becomes popular, as time passes there is an increasing probability of this happening. It would be best to try to reinforce the guarantee if possible. That would future proof that potential problem.

2. The ID generated with 8 bytes (64 bits) of entropy already makes brute-force attacks difficult (there are 18.4 quintillion combinations). However, I recognize that increasing it to 128 bits (16 bytes) would be even more robust. In any case, the practical risk of collision with 8 bytes is extremely low, considering this initial aspect of the project. But I may adjust this.

I'd like to propose another way of thinking for you regarding these matters. It is quite simple. If it does not cost you anything to improve it and if it does not have any real negatives, just do it. In this case, I think increasing it to 16 bytes costs you nothing and comes with no tangible downsides.  

3. I made it a priority to avoid any script execution or injected data. On the backend, PHP never returns the original message; only encrypted data. On the frontend, the message content is never inserted as HTML (only as plain text, via textContent). I will continue to monitor possible XSS vectors and if anyone finds any risks, let me know, I will try to resolve them immediately!

I ran it through some online scanners, and it looks good to me but they are not that in depth.

The goal of this project is to provide guarantees to the community that they can use it safely, so the code is open-source to facilitate community auditing.

I hope that you attract someone who is willing to review this properly and who has the capabilities. I'd suggest to look for some subreddits or cryptography mailing lists where it would be appropriate to announce this and ask for feedback.

For XSS I also ran it through this tool. https://github.com/s0md3v/XSStrike. Check it out if you are not familiar with it.

XSStrike v3.1.5

[~] Checking for DOM vulnerabilities

• Potentially vulnerable objects found

------------------------------------------------------------
3   setTimeout(function(){
4   window.location.reload();
2   function a0e(f,X){var n=a0n....

I shortened it because the output is a bit long and not needed. Try it yourself, it is a good tool!

Not a bit deal, but check out also your headers. They look pretty good, only minor improvements can be done. https://securityheaders.com/?q=https%3A%2F%2Ftalk2tag.com%2Fprivatetalk%2F&followRedirects=on. If you can then remove the PHP version information. It is better to limit information.

[joker_josue]

I hope that you attract someone who is willing to review this properly and who has the capabilities. I'd suggest to look for some subreddits or cryptography mailing lists where it would be appropriate to announce this and ask for feedback.

For XSS I also ran it through this tool. https://github.com/s0md3v/XSStrike. Check it out if you are not familiar with it.

XSStrike v3.1.5

[~] Checking for DOM vulnerabilities

• Potentially vulnerable objects found

------------------------------------------------------------
3   setTimeout(function(){
4   window.location.reload();
2   function a0e(f,X){var n=a0n....

I shortened it because the output is a bit long and not needed. Try it yourself, it is a good tool!

Not a bit deal, but check out also your headers. They look pretty good, only minor improvements can be done. https://securityheaders.com/?q=https%3A%2F%2Ftalk2tag.com%2Fprivatetalk%2F&followRedirects=on. If you can then remove the PHP version information. It is better to limit information.

Thanks for the tips, I will analyze these points in the next few days, to improve even more.

Was that XSStrike quote from your research for my site/script? I'll look into those tests, to see what I can do to tighten up security.

[Satofan44]

Was that XSStrike quote from your research for my site/script? I'll look into those tests, to see what I can do to tighten up security.

Yes, I downloaded it and ran it locally using your website as the target. What I quoted was the output that it gave me for your website. It is very easy to use, at least for doing the basic test anyway.  

[justinlamode]

Thank you for standing with privacy and I said this project is a very good one. I don't have much to say about this since the project already met most if the expectations of those who cherish privacy and also open source.

 My simple suggestion is if there should be a form of option by which an individual may want to say certain part of his conversation for future reference. Something a user can set up for himself for a specific duration, this way there will be some form of flexibility in how the platform works.

[Satofan44]

Thank you for standing with privacy and I said this project is a very good one. I don't have much to say about this since the project already met most if the expectations of those who cherish privacy and also open source.

 My simple suggestion is if there should be a form of option by which an individual may want to say certain part of his conversation for future reference. Something a user can set up for himself for a specific duration, this way there will be some form of flexibility in how the platform works.

Do you mean to say "save certain part of his conversation"? As for specific duration, there is already an expiration timer under advanced options. It lets you set it up to 7 days. Perhaps that is a bit too low if someone wants to send messages to the future.  Unless you are trying to say that you want the option for messages to stay alive for a specified amount of time even after being read?

[salad daging]

Usually I always use Zerobin or PrivNot to send messages about personal data, but now there is PrivateTalk which is much better than others, happy joker_josue you continue to do the best that makes Encrypted messages. In the future, maybe I will use PrivateTalk than others, it is more reliable.

[albon]

You’ve finally returned with an innovative project after the amazing image hosting platform TalkImg, which I still use to this day. Thanks joker_josue!

I’ve tried PrivateTalk, and honestly, what I liked most is the simple interface, the high level of privacy, and the fact that it doesn’t require account registration.

I tested [this message], and I’m now in the process of trying out the Dashboard.



But the message link is too long. Would it be possible to make the message link shorter?


Update: I set the message to be valid for 7 days, but every time I click the link, I get the following message:

"Message not found, already read, or expired."



Auto-Expiration time and Scheduled Message are not working, the message gets deleted immediately after the link is opened.

[justinlamode]

My simple suggestion is if there should be a form of option by which an individual may want to say certain part of his conversation for future reference. Something a user can set up for himself for a specific duration, this way there will be some form of flexibility in how the platform works.

Unless you are trying to say that you want the option for messages to stay alive for a specified amount of time even after being read?

Exactly what I was referring to and it's just a suggestion. If there is the flexibility of a user choosing to retain a certain portion of the chat for a long period, it will make sense since there are messages one might want to say for future use. The only exception to this should be when the sender does not want such message saved like we have "one time view only" in WhatsApp.

[TryNinja]

Very cool.

But I've found a major issue.

Let's say I create a note with the text "hello":

https://talk2tag.com/privatetalk/?id=2cc8ee9f95de51c3#eyJhbGciOiJBMjU2R0NNIiwiZXh0Ijp0cnVlLCJrIjoiajhfb2hGbnFuZGRYVnhyQ2hCWGNjX1VwOHBQOUhNQXVmbWR6Z1R6TU1uYyIsImtleV9vcHMiOlsiZW5jcnlwdCIsImRlY3J5cHQiXSwia3R5Ijoib2N0In0=

If I access the link above, everything works fine and I can read the note.

But if I create another one and use the wrong secure fragment, let's say:

https://talk2tag.com/privatetalk/?id=2cc8ee9f95de51c3#TOTALLY-WRONG-FRAGMENT

The message can't be read because the fragment is invalid, but the note is still deleted forever.

Shouldn't it only be deleted after it is actually read?