I ll be honest here: I litreally did this because i was getting tired of not being able to find a platform where i can be confident that: Yes, from an end to end there is no middleman snooping etc.
I ll publish the code on github too. The idea is that on every startup, system generates a new keys to encrypt data. This site is hosted on a single docker instance and there is no output (logs etc) for now. I dont intend to capture anything at all from this. Litreally. The dictionary lives in memory and there is a background service on the same docker that new(s) the Dictionary every 24 hours.
Unless I missing something, there are a ton of open source client side encrypted pastebins around.
E.G: 0bin.net (https://0bin.net/), with a lot of good faith in the FAQ (https://0bin.net/faq/), a basic and open source code (https://github.com/Tygs/0bin), zero JS stats on the main instance and alternative instances already in the wild. It does feature self destruct.
well now you have your platform where you can be confident that no one is snooping but if anyone else would like to use one too, they would have to make it themselves (or deploy your source code when you publish them)
2. Instead of very long hexadecimal UUIDs use shorter IDs with more valid characters. Do you really need 128 bits for something that has to be brute forced and only lives for a limited time? Perhaps 64 bits are sufficient?
Taking advantage of this post to ask about this -- can anyone explain to me why Signal can't be implemented as a completely offline-first/PWA web-app.
If we throw away the more advanced requirements of perfect forward secrecy, non repudiation, ratcheting for groups, non repudiation, why is it a bad idea to get 80% of the way there with basic offline-first/WPA (+/- secure enclave, WebAuthN, whatever else) messages that are stored on peoples' devices, encrypted before being sent out etc.
Excalidraw is an excellent app that's actually already written about this[0], so we know it's possible in some form. There's exciting p2p technology in the browser (ipfs, gun, etc). To reach all the platforms you could use Electron and in the future Tauri (which purports to be less of a drain on system resources), etc.
What am I not seeing about why this fundamentally can't be done and I can enjoy relatively simple encrypted chat without worrying about installing too many things, in a throw-away shell somewhat similar to pastenow.me? Is it just that no one has built it? surely not
NOTE -- I don't mind too much about not having to be online at the same time to share information with someone else, I don't think it's too hard these days to coordinate a time to share initial contact information/status
[EDIT] correct "offline" to "offline-first/PWA" since it was leading to confusion, didn't include the "-first" enough places, clearly.
I don't get it. Why would a messaging app be offline? Do you mean you could send out messages even while you're offline, and the app would wait until it has a connection and send those messages out immediately?
Sorry the offline there is "offline-first", you need offline-first (AKA modern PWA type technology/architecture) for websites to work well in patchy internet/etc. The "offline-first" phrase/terminology is well known in frontend circles but maybe not as widely as I thought.
Generally offline-first/PWAs can be made "installable" by setting metadata on the page that hosts them and doing other things.
The problem with web apps is that doing timing sensitive stuff such as encryption and decryption in javascript is risky and difficult. Javascript also takes a serious toll on performance and battery life.
I'm assuming "completely offline" means that it still sends some data somewhere, otherwise the messenger wouldn't make any sense.
I don't really understand the need for it to be a web app other than developer convenience. Electron and friends are a solution to the problem "I don't want to write Qt code", but a good platform for applications they are not.
Adding encryption (proper encryption) to the Telegram client would net you a fully native experience that works cross-platform without issues. Going native also allows you access to stuff like TPMs, although you can assume most desktop machines still don't have them. You also have much more control over the security properties of the code if you stick to native code.
The folks over at Matrix are experimenting with running their Matrix servers in a peer to peer configuration on the device itself. Stuff that server into a cross platform client like Fluffychat or Element and you've got yourself a chat app with federation and cross platform chat support without relying on any specific server.
If you want to stick to a browser only solution, I'm not entirely sure how you'd go about making that talk to other clients. IPFS requires access to a third party gateway, as do most peer to peer solutions. I think you can make WebRTC work as a means of full P2P through a DHT but I'm not entirely sure how.
The problem with a simple, offline, encrypted chat client is that it's not simple. Security is very hard; if you're willing to give that up, there's plenty of IRC web clients for you to choose from. If you've got any good ideas on how to build this, I encourage you to work it out and make a proof of concept, because it sounds like it could be very useful.
> The problem with web apps is that doing timing sensitive stuff such as encryption and decryption in javascript is risky and difficult. Javascript also takes a serious toll on performance and battery life.
This feels like somewhere WebAuthn and/or Emscripten/WASM help a little bit here? I'm most worried about vulnerabilities to the underlying protocol and less about perf/battery life (maybe some side-channel attacks?).
> I'm assuming "completely offline" means that it still sends some data somewhere, otherwise the messenger wouldn't make any sense.
Yes, I did a bad job of explaining this, but online-when-you-need-to-be. "offline" was meant to mean "offline-first", a common frontend terminology for PWAs.
> Adding encryption (proper encryption) to the Telegram client would net you a fully native experience that works cross-platform without issues. Going native also allows you access to stuff like TPMs, although you can assume most desktop machines still don't have them. You also have much more control over the security properties of the code if you stick to native code.
> The folks over at Matrix are experimenting with running their Matrix servers in a peer to peer configuration on the device itself. Stuff that server into a cross platform client like Fluffychat or Element and you've got yourself a chat app with federation and cross platform chat support without relying on any specific server.
Well that would be great, I'd love to just do that.
> If you want to stick to a browser only solution, I'm not entirely sure how you'd go about making that talk to other clients. IPFS requires access to a third party gateway, as do most peer to peer solutions. I think you can make WebRTC work as a means of full P2P through a DHT but I'm not entirely sure how.
I think you can get away with signaling (STUN/TURN) here -- if you have WebRTC you can go STUN-only and even if you have to TURN if you're sending encrypted data then it shouldn't matter. Honestly I think IPFS is actually overkill for this (though it has it's upsides), the only technology you really need for this to work is WebRTC + a STUN/TURN server.
> The problem with a simple, offline, encrypted chat client is that it's not simple. Security is very hard; if you're willing to give that up, there's plenty of IRC web clients for you to choose from. If you've got any good ideas on how to build this, I encourage you to work it out and make a proof of concept, because it sounds like it could be very useful.
But at this point we have methods that work, there's no need to rethink the primitives, we've got good well-tested schemes for sending simple messages. In the desktop world simply gpg encrypting and sending files is good enough (even a basic scheme with asymmetric crypto + nonce + symmetric key + symmetric crypto), why is messaging so hard as to be unattempted even in the 1-to-1 case?
Maybe the only way for this to really get it's tired kicked is to just build the thing in a weekend (if I'm right about it being so simple then it "should" be easy, right?) and post it to HN.
Edited for clarity, what I meant there was offline-first/PWA. The idea of being able to do things completely offline and use some other medium is also interesting, but what I mean to convey is web apps built with the expectation that the internet may not be connected (and keep working).
Generally offline-first/PWAs can be made "installable" by setting metadata on the page that hosts them and doing other things.
Yeah ScuttleButt just seemed to have too much going on, I haven't looked at it in a long while (and have no reason to). I invested some time into figuring out the difference between scuttlebutt, IPFS, gun and others but it was a bit of a headache. It does feel like one of them can get you 90% of the way there though.
Some people do, but not everyone, and I'm personally not interested in an app that does it perfectly but no one can use.
Also, I did not mean to imply that the features could not be done -- they ostensibly can, it's just that I am not willing to accept the lack of them or possible lack of them as a reason, because a lot of people don't even know it's happening/don't know when it's missing. More interested in increasing the base of people who use more secure messaging that is more independent and simpler to understand where possible.
The whole point of signal is that it's secure and has reasonable UX. As soon as you can start choosing security parameters it becomes unnecessarily complicated for the average person with added scope to mess something up
Well the question is is there an even easier signal that is some reasonable mix of secure and reasonable UX? There are important features that Signal has left out (not requiring a phone number to sign up being the most egregious) -- the question I'm asking is whether there is another point in that space of tradeoffs.
Hi, normally i dont post at all. But this is my attempt to share pieces of information anonymously that expires in a certain time. Site is made in Angular and and the backend is a simple thread safe dictionary that resets every 24 hours. It is by no means a commercial solution to any problem. This is something i came up with half an hour of dev work, coz i could not find anything similar.
It looks very good for something whipped up in an hour. Did you consider using Redis as a data store for this? Seems like it would be quite easy to just generate a UUID as a key and set it with an expire time in redis. If you did consider Redis, any reason why you didn't end up using it?
If you want privacy and anonymity, be careful about how you're generating your UUID. Some flavors of UUID are just the MAC address, process ID, and timestamp, which makes them trivially guessable (and poorly scalable).
Instead of a UUID, just read 16 bytes from /dev/urandom (getentropy() if you've got it). Base85 or Base64 encode the bytes if you need a string.
It was over 20 years ago now, and I don't remember which library it was, but I ran across a type-1 UUID library that stored the timestamp of the latest UUID it handed out in a static (or maybe thread-local, I forget) variable, and would nanosleep until the system clock next ticked if it had already handed out a UUID with the current timestamp. So, you were limited in your UUID generation rate by the resolution of the system clock.
(I guess the fear was that it was theoretically possible for the process to crash and come back up with the same PID/TID within the same system clock tick, if the machine were really chewing through processes rapidly. It's good, as they aren't called Nearly Unique IDs, and the main use for type-1 UUIDs would be if you're paranoid about RNG collisions, but it does limit you to one ID per system clock tick, even though the timestamp in the type-1 UUID is actually 100-nanos resolution.)
A better solution would have been to query the system clock resolution, at library initialization time check the current system timestamp, and use the low bits of the type-1 UUID timestamp as a counter, being careful to never catch up to the current time. The library wouldn't have been able to hand out any UUIDs during the first system clock tick after library initialization, but after that, it could hand out up to 10 million UUIDs per second per thread. If that's not fast enough, one could also have it check for multiple network cards and use a pool of MAC addresses instead of just the primary interface's MAC address.
The UUID RFC is from 2005, but they're also documented in the ISO/IEC 11578:1996 standard.
As I mentioned, a good type-1 implementation uses a counter to simulate a higher resolution system clock to get around the system clock resolution limiting scalability. Also, I'm guessing you're generating type-4 (random) UUIDs instead of type-1 (MAC address and timestamp), right?
My point is that if you're generating UUIDs rapidly, check that you're either generating type-4, or that you're using a high-quality type-1 implementation that simulates a higher resolution clock using a counter.
I never really got the point of (digital) self destructing messages, since the reader can easily just copy the text/data, i.e. destruct only means not available anymore after future point in time. So you're just relying on the receiver of the message to follow protocol -- as always.
I use it a lot with my friends (Signal) when speaking in very sensitive subjects instead of deleting messages manually you just make sure that messages will not be available after a specific time so you are safe if someone hacked your phone. and yes it's very useful if both parties agreed to it. is not security against the one who are chatting with but the one who might access your data one day.
I hadn’t thought of it that way. I guess it’s like shredding mail is completely normal, but in a digital world we’ve become accustomed to the idea that you keep every single letter forever.
It protects you from negligence, not malice of your conversation partner. There is an obvious design trade-off since people might use this feature in a wrong setting.
Imagine two parties trust each other to have the right intentions but imperfect endpoint security. If they send private data to each other, isn’t it better for messages to expire after a useful window in case either is compromised in the future? Same reason we have expiring JWTs
I usually use https://onetimesecret.com/ for sharing secrets. Its code is also on github, so you can install it in your own environment, too, if you don't trust the author.
I use https://www.saltify.io however I didn't know onetimesecret is open source, this is helpful as we use it a lot at work, seems worth building our own. Thanks for sharing that.
yeah, was thinking about rebuilding it as OSS just now.
the biggest problem is that a security-minded org is going to want control over the server storing their secret messages (otherwise, you're literally giving away which org you are (slackbots get your org id) and your deepest secrets to a third party)
to self-host, i think the slash command setup is more complicated/annoying. but i will look in to it again.
edit: and you can't really do E2E encryption with slack as a middleman to your API
I ll publish the code on github too. The idea is that on every startup, system generates a new keys to encrypt data. This site is hosted on a single docker instance and there is no output (logs etc) for now. I dont intend to capture anything at all from this. Litreally. The dictionary lives in memory and there is a background service on the same docker that new(s) the Dictionary every 24 hours.