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?
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.
