Fileghost 0.0.1 Released. ¯\_(ツ)_/¯ | Hacker News Reader

Fileghost 0.0.1 Released. ¯\_(ツ)_/¯

github.com

1 point0ut0flin312 comments

As others said this is very weak. The implementation seems to be that you generate a random permutation of the values 0 to 255 and use it as a lookup table. An even simpler and faster approach would be to generate a random stream of bytes and repeatedly use it to xor the input bytes (wrap-around the key if the data to encrypt is longer than the key). This shouldn't be any weaker, and has the added bonus that the encrypt and decrypt function are identical.

Also, don't call it private key. That term is reserved for asymmetric encryption. This here is just a key.

Thank you for the suggestions and clarifications. What exactly do you mean by wrap-around the key?

Something like

  for p = 0 to inputLen-1
    Output[p] = Input[p] xor Key[p mod keyKen]
  next

The modulo makes the key wrap around, so it doesn't matter how long or short it is compared to the input data.

COOL! it works like a charm!

in any case,[I'm going to personal logic.] I was thinking back to the fact of the weakness you mention of the method I used which, said by more than one person, I don't question it. But I don't understand how that is possible. So, if I have a key that only I know, which would be an array of length 256 which always contains all the numbers from 0 to 255 but in random order. and for each byte (p) of the input file I replace p with key[int(p)]....it seems really impossible to go back to both the input and the key. due to the fact that I can't know what it was before the replacement. What am I missing? Of course there can be repetitions in the bytes and then you can draw conclusions as to what byte it is,yes..but also think if I repeat the same, several times, with different keys? However, your function rules, I will implement.

It really depends on several factors, and won't be something you crack in 5 minutes. But let's say you have a hunch of what the original data was. If it was plain text and you know what language, you can pull up statistics of which letters appear with which frequency in that language. The longer the encrypted data, the better those statistics will apply. So you just take whatever byte appears most and assume it's an "e" (or whatever) and work your way from there.

If you know the input must be a jpeg, you can look up the file structure, especially the header, so you already know what the first couple bytes of the decrypted file have to look like. Boom, you already know the first couple bytes of the key. And no matter whether you use your original method or the xor method, if you know the length of the key, for example 256, you can also immediately decrypt a few bytes every 256 bytes into the file. You can then work your way from there, using other properties of the file type you're trying to decrypt to.

If you know multiple files have been encrypted with the same key, it gets even easier as you can infer information across all those files.

The xor method would only be truly safe if your key is as long as the data to encrypt, never gets reused and was generated using a secure random number generator.

Thanks for the reply, I'm really pleased with an external opinion, I'm really wasting a lot of energy behind it! You're right, you can recover some bytes by "intuition" in fact now I'm applying some changes and will publish a new version. In particular, the xor function you proposed will be added to the bytes encrypted with my original method, so the xor function will not be "alone" but will be accompanied by the original method of 256 bytes. Furthermore, as you rightly said, even if by merging the two functions are still very secure, it would be much safer if the key has the same length as the input and in fact in the next version the key will be generated especially for the file, or it will be possible to encrypt only a message or a file of maximum length 256 bytes so that the keys do not have to be modified or lengthened. Now I'll see what's best. Once some changes are applied I think it can come in very handy and it's also super lightweight. I'll get to work, I'll put another submit here when it's ready and WELL DONE.

new version https://0ut0flin3.keybase.pub/fileghost/README.md

Fileghost allows to encrypt any file (or sequence of bytes, like a message) using an unique, random generated sequence of 256 bytes. Keybase Team: https://keybase.io/team/fileghost_team

This is pathetically weak and should never be used for any purpose other than maybe as homework to break in the first week of cryptanalysis 101.

Yes, if the file size is small then an attack is possible. But if it's big, it's really very difficult. I'm also working on a pre-mask that removes repeating bytes from the input and makes it impossible to get double characters. It's just an experiment, I'll also put an encrypted file with a prize for whoever reveals the original file! Apart from these problems that are there, how are you going to guess a sequence that can have 256! different combinations and can be encrypted with several different keys?

> Yes, if the file size is small then an attack is possible. But if it's big, it's really very difficult.

Big files make the attack even easier.

> It's just an experiment, I'll also put an encrypted file with a prize for whoever reveals the original file!

Good idea.

> how are you going to guess a sequence that can have 256! different combinations and can be encrypted with several different keys?

Because there are other attacks possible besides just brute force.

Reply on news.ycombinator.com