{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia4yyzozeploqo2hjbyfn6kg2m6pobzt5dlujwjfsiggg57klrake",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mmjna7kcqby2"
  },
  "path": "/t/recommending-an-encryption-software-by-paranoia-works/38091#post_4",
  "publishedAt": "2026-05-23T13:12:34.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "VeraCrypt",
    "Signal",
    "Cwtch",
    "age",
    "Dyson Sphere"
  ],
  "textContent": "JohnDose:\n\n> In case you haven’t read, detailed specifications of file encryption can be found here:\n\nNo I didn’t.\n\nThe 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:\n\nThe 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) is fine.\n\nIt’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.\n\nLocking 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.\n\n2048-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.\n\nConsidering 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.\n\nWhat 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.\n\nAnother scary sign is they calle 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.\n\nI’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.\n\nThere’s good encryption tools by respected researchers already:\n\nIf you need to encrypt hoarded data for yourself, use VeraCrypt.\nIf you need to encrypt data you send to contact, use Signal/Cwtch.\nIf 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.\n\nThere’s zero reasons to go past 256-bit encryption. The easiest proof of this is this:\n\n  * Suppose you have theoretical perfect attack algorithm that takes exactly one bit operation to test one key.\n  * 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.\n\n\n\nTesting 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.\n\nSo if you could attach a Dyson Sphere with perfect energy efficiency into every single star of ~every single galaxy for 100 years, to feed the most energy efficient computer that the laws of physics allow, yeah, you could probably break one AES256 key.\n\nThe only reason you’d offer more than 256 bits is for the same ridiculous security margin against quantum computers, and then you’d just use 512-bit threefish.\n\nThis 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.",
  "title": "Recommending an encryption software by Paranoia Works"
}