3 ms·

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

iforgotpassword 4y ago
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.
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
- 0ut0flin3 4y ago
  COOL! it works like a charm!
- 0ut0flin3 4y ago
  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.
  - iforgotpassword 4y ago
    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.
    - 0ut0flin3 4y ago
      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.
    - 0ut0flin3 4y ago

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.

deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
0ut0flin3 4y ago
COOL! it works like a charm!
0ut0flin3 4y ago
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.
- iforgotpassword 4y ago
  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.
  - 0ut0flin3 4y ago
    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.
  - 0ut0flin3 4y ago