Recommending an encryption software by Paranoia Works

Site Development Tool Suggestions
1

Website

Short description

Encrypts file and text using state-of-the-art cryptographic algorithms. Also has a quantum-secure KEM key exchanger and steganography tool.

Why I think this tool should be added

I got to know this software a few days ago while searching for encryption algorithms that has a key size greater than 256 bit. Cryptographer Bruce Schneier’s blogpost( Threefish - Schneier on Security ) about Threefish contained a link to this product(not any sort of an affiliation, just to show a real-world implementation of the Threefish algorithm).

This software satisfies the following criteria for encryption software:

  1. It is cross platform and open source. Source code can be found at Paranoia Works Encryption Tools 🛡️ | Downloads
  2. File encryption app support encryption/decryption on Windows, MacOS, Linux, Android, and iOS

*It does not have disk encryption functionality, so the relevant criteria do not apply to this software.

I’ve never heard of this before, but it seems to have been around since 2011(at least, that’s what I can find on the Google Play Store history). And although I didn’t know about Paranoia Works itself, the online link encryption tool(https://linkenc.net/) I’ve been using for many years was also made by them. They also provide other security tools(password generator, URL has generator, file/text encryption) that fully functions offline inside the browser.

To mention a few drawbacks,

  1. The UI is quite old. It’s simple but surely not modern.
  2. It lacks any external audit

Other than that, I can’t find any specific reason to NOT recommend this software. And I also couldn’t find any notable reviews of this software on Google either. I did stumble upon this reddit post( Reddit - Please wait for verification ), which says that the steganograpy tool leaves a copyright signature, but when I checked it myself, it didn’t leave any JPEG comments.

The only other issue I found is that the Paranoia C4 algorithm, which is a cascade of Threefish–Serpent–AES–SHACAL2, is shown in the program to have a 2048-bit of security, while strictly speaking, it doesn’t. I sent an email about this and below is the reply I received from the devs(which to me, sounds quite reasonable).

“Paranoia C4
The number simply represents the key length. This is commonly used for cascades — I haven’t seen VeryCrypt in a long time, but its predecessor TrueCrypt used 768-bit for a cascade of three 256-bit ciphers (just like double DES used 112-bit). And it has to be labeled somehow. If I wrote some number between 256 and 1024, I’d have to explain MitM attacks to someone every other day and why it’s not 2048, and every third day I’d end up in academic debates with people who know what it means but still think that from perspective X, assuming attack Y, it should really be number Z instead. These discussions are a complete waste of time anyway, because attacking such a cascade would require 10^231 bytes of storage, so even if we managed to store one byte in every atom of the observable universe, you’d still need 10^151 universes’ worth of storage — damn, here comes the academic debate again :).”

And for the external audit, devs replied:
“External audit:
The application will never make enough money to pay for a real external audit — not even in a thousand years.”

FYI, the software supports the following algorithms for file and text encryption: AES(256), RC6(256), Serpent(256), Twofish(256), GOST28147(256), Blowfish(448), Threefish(1024), SHACAL-2(512), and the Paranoia C4(cascade of 4 algorithms). The last few algorithms are only available on PRO version, which costs about 5$ USD. It supports ML-KEM-512, 768, 1024 for KEM key exchange. Steganography algorithm can be chosen from either F5 or J-UNIWARD.

Section on Privacy Guides

Encryption Software

2

The algorithm choice is not job of the user. Any modern tool needs opinionated cryptography, i.e. the author shows their expertise and pick the most secure option

Serpent and Rijndael I.e. AES are both SP-network ciphers. While Serpent was slightly stronger than Rijndael on paper, the latter has seen MUCH more cryptanalysis over the past two decades. That’s why you’d want to trust AES instead.

What matters more is how you deploy your AES, e.g. ECB is broken, and GCM is best practice.

But AES requires hardware acceleration / native instructions to protect from cache timing attacks. Serpent also has its own S-box but no CPU can run it efficiently (if at all) in constant time.

So if the platform support includes devices without AES-NI, using ciphers that don’t require native instructions, like ChaCha20-poly1305 make much more sense.

Threefish uses 512 bit keys but unless you deploy pre-shared keys, the key exchange
like ML-KEM1024 will set the security margin as the weakest link. It actually gets worse, more about that below.

Plus we don’t really need 256-bit security margin against Grover, AES-256 has more than 128 bits of security against Grover in practice (see Valsorda’s recent blog posts). Also with it’s minimal cryptanalysis, it makes less sense to use threefish even when I trust Schneier and his expertise. It’s unfortunately not up for him at this point.

RC6, Twofish, Blowfish and SHACAL are also much more obscure and less reviewed.

GOST is a Russian cipher, you don’t want to even offer it.

The cascading ciphers make no sense, as all ciphers will use a key that in the best case come from your OS kernel CSPRNG. For Windows that’s AES, for Linux that’s Chacha20.

Since both are 256-bit algorithms, that will cap the security of bigger keys like Threefish, where you need to force user to wait 301 seconds on Linux for the OS to reseed the CSPRNG, to generate second half of the key from independent entropy.

If the cipher used in the random number generator has a vulnerability, that’s enough to break all four distinct ciphers. Even if the RNG is fine, and you use different cipher from the CSPRNG, you now have second point of failure that can fail independently.

This is why I prefer to minimize trust in primitives: Linux RNG is ChaCha20 based, so I need to use and trust ChaCha anyway.

So I use XChaCha20-poly1305 as cipher, and ChaCha based hash function (BLAKE2b) and BLAKE2-based PHF (Argon2id).

These are considered high end primitives and due to their popularity they receive majority of the attention.

Also, poly1305 is a Wegman-Carter MAC so it’s provably secure if ChaCha20 is secure, which is much better than AES-GCM’s GMAC that has a paper about it’s fragility which means trouble when implementing.

Dont get me wrong, I’ve also been where you stand, unable to decide, implementing cascading encryption and robust combiners for hash functions, but none of that is needed.

Your main problem will be key management, correctness of implementation, and software security in general.

Cipher choice is best left as “boring but best practice” because they already provide an abstraction to the “super duper extra ultra high security”, it’s just not called that by reserved academics who prefer to use the term “computationally secure”.

Also like Snowden said, NSA won’t break ciphertexts. They will hack your computer and bypass the encryption.

3

Thanks for sharing your insight.

In case you haven’t read, detailed specifications of file encryption can be found here: S.S.E. File Encryptor - Format Specifications
According to that page, all ciphers operate in CTR mode. (which is probably less desirable than GCM? Idk)

Threefish can use key size of 256, 512, or 1024 bit (which are equal to block size). This software in particular, uses the 1024-bit version (as written in the bottom of my post)

4

No I didn’t.

The CTR mode is not bad in of itself. It’s parallelizeable i.e. you can use multiple CPUs to generate keystream blocks before XORing the plaintext. You just need to pair the CT with a MAC which they do:

The BLAKE3 MAC is generally secure, Encrypt-then-MAC is best practice. But SHA3-MAC is non-standard to the point you usually have to pop the hood and implement it yourself, so it raises some eyebrows. It’s not hard. Luckily SHA-3 onwards hash functions have had to be immune to length extension attacks so BLAKE3(K||CT) works and it’s hard to shoot yourself in the foot.

It’s also a bit weird that the Serpent is the only one where the implementation is provided. This is one of the most important aspects to communicate: who implemented the cryptography.

Locking the 512-bit+ ciphers to PRO version when the key exchange or CSPRNG can’t provide more than 256 bit keys is also a bit telling about the project.

2048-bit salt is over-kill. The only point of the salt is to ensure that the password and its hash won’t be in the attacker’s dictionary. Salt beyond 128..256-bits is probably intended to be less concerning, but there’s a bathtub curve in the amount of concern I have as a function of crypto variables’ sizes. This definitely hits the latter peak.

Considering the absurd key sizes the Argon2id parameters have ridiculously low parameters. 10240kB = 10MB memory cost is absurd given that most platforms have gigabytes of free RAM. You shouldn’t add time cost unless memory cap puts the derivation time below desired key derivation time range.

What gets even crazier is the project offers a Web-UI for the encryption tool. Which is nothing short of horrible. Every time you load that page, you load another copy of the source code. You can’t really inspect the code (WebAssembly and all), and if one day you get a one-time backdoored version, your browser won’t retain any audit logs. This is the extreme opposite of best practice, where you’d grab a copy of the application source code from GitHub, check it for correctness, compile it yourself, and use it.

Another scary sign is they called AES-256 “military grade” This is another novice landmine. Military grade encryption has these days nothing to do with key sizes, a bit to do about the algorithms (Suite-A or Suite-B as per use case) and everything to do with the formal evaluation of the implementation. Military grade would imply a team at the NSA IAD takes several months or years to verify everything from the cipher implementation to the FPGA circuit running it inside some Harris military radio. Calling some website binary blob military-grade is snake oil marketing.

I’m too old to do a deep dive into stuff like this, but these red flags are enough for me to say: Absolutely do not use this program.

There’s good encryption tools by respected researchers already:

If you need to encrypt hoarded data for yourself, use VeraCrypt.
If you need to encrypt data you send to contact, use Signal/Cwtch.
If you somehow need this really wonky use case of just encrypting a file individually for some weird case and VeraCrypt container isn’t an option, use age.

There’s zero reasons to go past 256-bit encryption. The easiest proof of this is this:

  • Suppose you have theoretical perfect attack algorithm that takes exactly one bit operation to test one key.
  • Suppose you have a theoretical supercomputer that operates at the perfect energy efficiency. The laws of physics state that a single bit operation must consume at least 2.9×10⁻²¹ Joules of energy. This is called the Landauer limit to those who want to dive a bit deeper.

Testing 2²⁵⁶ keys would thus consume at least 10⁵⁶ Joules of energy. Breaking single key in 100 years (3155760000 seconds) would require 10⁴⁶W energy source, which means you need 10²⁶ Suns. Average galaxy has 100 million stars. So we need 10¹² galaxies, which hits the middle of estimates of how many galaxies there are.

So if you could build a Dyson Sphere with perfect energy efficiency around every single star of ~every single galaxy for 100 years, to feed the most energy efficient computer that the laws of physics allow to run a hypothetical perfect algorithm, yeah, you could probably break one AES256 key.

This is why anyone offering more is usually more telling that they haven’t done the math about key sizes, or they want to scam people who haven’t done the math by selling something that nobody needs.

The only reason one should ever offer more than 256 bits, is to provide same security margin against quantum computers: In that case I’d understand the 512-bit threefish. But that will again require jumping through extra-hoops in keygen phase to ensure there’s actually 512 bits of entropy.

5

The argon2 parameters being way too low compared to other variables definitely seems strange to me too.

However, I don’t see anything problematic with them providing a web-ui. It’s just an option afterall. They neither force users to use the web version nor provide exclusive benefit over the installed version, and it’s completely up to the end user to choose which one they use.

I was looking for such tools because I have a use case where I need to encrypt individual files, not a whole drive or a container. PG used to recommend Picocrypt(which uses stream cipher), but the original project is no longer maintained.

About the security of AES-256, although I know nothing about cryptography, I do think there is a possibility that undiscovered attacks using quantum computers (or even conventional computers) may be found (or is already found, but just hidden to the public such as in the case of DES( Data Encryption Standard - Wikipedia )). I don’t immediately consider AES-256 as insecure, but I also believe it isn’t flawless and will stay as strong as it is today until the end of the universe. That’s why I was looking for alternative encryption algorithms, preferably with larger key sizes. But I guess this program just ain’t as good as it looks to be.

6

It’s a footgun. Cryptography lives from stuff like best practices, opinionated crypto, and also, misuse resistance. Since it’s not safe to use and requires blind trust on every session, offering it in the first place shows incompetence and when paired with usual novice mistakes it doesn’t inspire confidence in the project overall.

Cryptography is the structural integrity engineering of digital infrastructure. You don’t want amateurs designing or building bridges, or designing materials used to build them. So you don’t want amateurs designing the ciphers, implementing them, or writing protocols and software that uses them.

undiscovered attacks using quantum computers

It’s much more likely there’s an undiscovered attack against RC6 or Blowfish because these ciphers aren’t being analyzed anywhere nearly as much. For quantum computers, the best attack we know is Grover’s algorithm, and it can’t break even AES-128 in practice.

it isn’t flawless

Sounds like you’re trying to market the cascading encryption indirectly. Again, if ChaCha20 or AES is broken and the generated random key is predicatable, it doesn’t matter which algorithm you use. And no matter what the system will rely on ML-KEM for key exchange, that’s another single point of failure. It’s much more probable these new post-quantum kex algos have problems than extensively analyzed symmetric ciphers. I’ve never seen concerns towards AES or ChaCha.

I know nothing about cryptography

I think this says more than the “I also believe it isn’t flawless”. AES isn’t flawless, but the interesting part is how big of a dent has the entire academic community managed to make. The Biclique attack is the best classical one yet, and it has managed to reduce key size by a whopping 1.6 bits. So AES256 is now AES254.4. The standard rule of cryptography is that attacks only get better, but quarter of a century later, Biclique attack is like a paint scratch in an aircraft carrier’s hull.

That’s why I was looking for alternative encryption algorithms, preferably with larger key sizes.

Again, nobody is breaking AES ciphertexts with some secret quantum algorithm. Any attacker will have a budget and to them the bang for buck is currently in “Let’s put Claude Mythos find a zero day in the operating system, and hack the computer / phone and watch the target type the message and exfiltrate the plaintext or the key(s).” Finding the zero day costs maybe 50,000 USD, after which it can pwn targets for 1-120 months until it’s detected and patched. That’s fractions of a penny compared to the crypto nerd’s fantasy.

image
image448×274 23.7 KB