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

@[email protected] 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.

  • FrederikNJS@lemmy.zip
    link
    fedilink
    arrow-up
    28
    ·
    edit-2
    1 hour ago

    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.

    EDIT: apparently I can’t operate a calculator

    • LostXOR@fedia.io
      link
      fedilink
      arrow-up
      4
      ·
      8 hours ago

      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?

      • FrederikNJS@lemmy.zip
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        1 hour ago

        Oh shit! You are completely correct… I looked up my math, and apparently I put a mutiplication sign instead of a power-of sign…

        That’s horrifically wrong, but as you mention, still not strong enough…

        I have struck out the parts where I was wrong.

    • RommieDroid@programming.devOP
      link
      fedilink
      arrow-up
      9
      ·
      12 hours ago

      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.

    • TehPers@beehaw.org
      link
      fedilink
      English
      arrow-up
      2
      ·
      13 hours ago

      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.