Update
You can now encrypt plain text, so anything you want. With this, you can send sensitive information over insecure channels or share publicly with real plausible deniability. (below 2000 characters works without issue)
Changes
I rebuilt the system with a different encryption design, and address many of the flaws pointed out in V1.
I really wanted any password to always decrypt so you never know if you are right. I found the XOR algorithm that does this, but there is an entropy problem, where an incorrect password will almost always output non-common characters, I attempted to solve this at its core by diving into the math and some research papers but got nowhere, as it seemed to be almost impossible.
I tried finding an algorithm that would give me perfect plausible deniability, so if you shared a link X with a password you could use a different password and get Y, saying you never intended to share X. It doesn’t exist 😢 I came up with a workaround by adding decoys which are mutable XOR ciphers joined, it allows you to set what other data is included, so you can tailor your alibi.
Here is the demo link. There are three memes you can find
Password: test1, test2, test3
Safety
It should be safe to share data encrypted with this method, I did some basic brute force tests and did not find any shortcuts, I have a rough estimate of a billion years on a server farm for a 12digit password.
Considerations
@calcopiritus@lemmy.world said:
“There’s 2 secrets here: the link and the password. And to share it with someone you need to share 2 secrets: the locked link and the password.”
A strong password is almost impossible to crack, but you can use a popular text link tool like pastebin with expiry to mask the encrypted data. As for eliminating the password, I have considered using the site as the ‘shared secret’ so you share just the cipher, and if you know the URL you can paste it in, and it would be encrypted/decrypted with a derived key the site stored.
So this basically runs key derivation by taking the password, SHA-256 hashing it, and feeding the result to a SecureRandom. Then XORs the output of SecureRandom with the plaintext in CBC mode with a block size of 1 byte… CBC meant this isn’t protected against tampering, since the encryption mode isn’t authenticated. And the blocksize of 1 byte, means you can attack each character of the ciphertext one at a time.
This is a woefully inadequate key derivation, and the actual encryption seems fairly flawed. I only have a basic Cryptography 101 course under my belt, and while I don’t have the skill to obviously break it, it absolutely makes the hair on my neck stand up…
Discounting any weaknesses in the actual crypto, the heaviest part of this algorithm is the actual SHA-256 hash, and with some tweaking, I’m sure someone determined could modify hashcat to attack this encryption directly. I just had a look at some Hashcat benchmark on an AWS p5en.48xlarge instance, which has 8x Nvidia H100 GPUs. These together can churn out 126.9 Giga-hashes per second on SHA-256. Which means it can try ALL alpha-numeric passwords with 12 characters in just around 0.59 nanoseconds. This instance isn’t cheap, as it costs around $64 per hour to run, but at that speed you don’t have to run it for very long anyway.
So even at the worst-case, of having to brute-force your XOR encryption algorithm, breaking it will be trivial.
Please don’t roll your own crypto… Or if you do, please make it very clear to anyone that it’s your own hobby project, and that it shouldn’t be relied upon for actual security.
I agree with most of your comment, but your math is very wrong. 36^12 hashes (lower case alphanumeric) / 126.9 GH/s = 33.7 million seconds, or about 1.18 years. Still way too weak for secure use, but about 16 orders of magnitude above the nanosecond range. How’d you calculate that?
Oof 😅 0.59 nanoseconds. I dang messed up. This would be a good project for students to identify the weaknesses. Like the Theprimeagen says the problem with the tutorials is they’re neatly packaged, refined end products and you miss out on all the learning and debugging. You sound like you know what you’re talking about and the 1-byte block size is a huge mistake. I think I’ll do some more research into the different algorithms. Thanks for having a look, and weighing in.
This is why claims about security should always be backed by an audit. Someone will inevitably (rightfully) tear you a new hole if there’s any gaps.
What do you mean, the XOR Algorithm?? For this case, an AES-256 GCM AEAD (Authenticated Encryption, possibly with Associated Data) seems like the perfect use case. AES GCM is usually the most secure mode.
I hope you didn’t literally use XOR, so like you have some key stream the length of your data, XOR the key stream with the data to get some output. This is what some modes do internally, like AES CBC, but for an application you should just use something from a stable crypto library.
If anything, keep to Rule Number 1: Never do your own Crypto.
I hear you, XOR is bad 💀 I should just use the crypto library.
If you like experimenting with cryptography check out circom, it’s a relatively simple language to program zero knowledge cryptography. I was the head of development at a programmable cryptography research and development organization for a bit, it’s fun stuff, we researched and experimented with zero knowledge proofs, multi-party computation, and some more far fetched stuff like fully homomorphic encryption and indistinguishablility obfuscation. What you are trying to do definitely can be done with zk.
Also, please never use xor again lol
The cutting edge/novel techniques was what I was looking for, this is really cool. I’ll look into it more.
I hope you didn’t literally use XOR
It’s XOR(key, block) with IV and chaining: https://github.com/RommieEcho/qrcatalyst-open/blob/main/src/routes/anon/XORCipher.js
Since it’s chained at the byte level, you can strip it out by just XORing each byte against all following bytes. Then the IV can be XORed out of the first block, at which point you have just a series of XOR(key, plaintext) blocks that can be attacked with conventional methods.
:(
tech noob here, why is what he did bad?
Cryptography is the practice of hiding and protecting information.
Modern cryptography is about computer algorithms.
These computer algorithms are notoriously hard to invent, and even just to implement.
Cryptography is a constant cat and mouse game. Some people will attempt to build new algorithms, and some people will be trying to break these algorithms. In some situations people are doing this benevolently, where researchers will look for weaknesses so they can be fixed. In other situations people are malicious and an looking for weaknesses to exploit them.
Inventing a new algorithm usually takes years, and then it’s researched for even more years to make sure there are no obvious weaknesses.
Then people implement these algorithms and these implementations are then again researched for long times to look for weaknesses.
Inventing a new algorithm is insanely hard, and only a rather small amount of people around the world has had decent success.
But even if you have a good algorithm that is theoretically secure, then when you try to implement it in actual code, it’s again incredibly easy to make mistakes that completely undermine the security.
What the OP did was to try to invent a new algorithm. OPs algorithm is very flawed and easily broken. Then OP wrapped it in a Web page that purported to allow you to securely encrypt something. And used words like “crazy strong encryption” which could lead others to think the service is safe and secure, and rely on it for something critical, only for their security to be utterly compromised.
The mantra in the security community is “Don’t roll your own crypt”, and OP rolled their own crypto, and failed, without giving a proper disclaimer.
Understood, and thank you very much for the summary
Never do your own Crypto
Figured this needed repeating not at the bottom
Setting aside the cryptographic merits (and concerns) of designing your own encryption, can you explain how a URL redirector requiring a key would provide plausible deniability?
The very fact that a key is required – and that there’s an option for adding decoy targets – means that any adversary could guess with reasonable certainty that the sender or recipient of such an obfuscated link does in-fact have something to hide.
And this isn’t something like with encrypted messaging apps where the payload needs to be saved offline and brute-forced later. Rather, an adversary would simply start sniffing the recipient’s network immediately after seeing the obfuscated link pass by in plain text. What their traffic logs would show is the subsequent connection to the real link, and even if that’s something protected with HTTPS – perhaps https://ddosecrets.com/ – then the game is up because the adversary can correctly deduce the destination from only the IP address, without breaking TLS/SSL.
This is almost akin to why encrypted email doesn’t substantially protect the sender: all it takes is someone to do a non-encryted reply-all and the entire email thread is sent in plain text. Use PGP or GPG to encrypt attachments to email if you must, or just use Signal which Just Works ™ for messaging. We need not reinvent the wheel when it’s already been built. But for learning, that’s fine. Just don’t use it in production or ask others to trust it.
Hey, thanks for the thoughtful breakdown. I probably should label it: warning random IT grad project. I mistakenly believed I could make something that was good, well it’s a lot more difficult. You’re right that this doesn’t provide the kind of plausible deniability I initially hoped for, the decoys were just a workaround, because I couldn’t find the type of algorithm I wanted.
The query parameters are masked with HTTPS so you’re not revealing any extra data, it would just look like any other redirect if you were packet sniffing. And when visiting the destination links, your normal OPSEC still applies, like changing your DNS, using a VPN, etc. I was just seeing if this project would find some sort of use, but I only spend two days on it and it was a fun learning experience.
I was also confused at first, but OP is using “plausible deniability” to mean “depending on what decryption key you attempt to use, you get different ‘decrypted’ data”, so you can have an alibi I suppose. Not “plausible deniability” in the sense of “plausibly this isn’t encrypted at all”.
Yeah, it’s much harder to completely hide the fact you’re using encryption.
