encryption

  • 8 Replies
  • 3296 Views
*

Offline TechnoGeek

  • 238
  • 0
  • My new project, Notroid
    • View Profile
encryption
« on: June 23, 2009, 23:10:27 »
I'm working on an encryption program, and part of the algorithm is:
(k=one byte of key)
(m=one byte of message)
is the algorithm
Code: [Select]
result = ((m - k) XOR k) + k insecure? in other words, is it possible to get m without k?
Spoiler: Technogeek's Signature (click to show/hide)

*

Offline Krumel

  • 33
  • 0
  • One can be dividided by Zero!
    • View Profile
Re: encryption
« Reply #1 on: June 24, 2009, 17:59:21 »
I think it's a bit unsafe, because the key is a byte. So anyone who wants to decrypt, "just" needs 256 tries.
And if the informations are very important, that's definitely to unsafe.


*

Offline Gaeel

  • 75
  • 0
    • View Profile
Re: encryption
« Reply #2 on: June 24, 2009, 19:58:30 »
Code: [Select]
result = ((m - k) XOR k) + k
I'm not sure what the XOR does, I'm guessing the XOR toggles between(m - k) and k depending on a condition.

If that is true "result" is either 2k or m
That would be VERY insecure (and also inefficient) since m is plainly readable when XOR is true.

Unless you mean "bit" instead of "byte"... and that would mean I need to think a little more...
Code: [Select]
<Gaeel> I love you Dataflashsabot!
<Dataflashsabot> I love you too Gaeel!
<Gaeel> Wait are we really having this conversation?
<Dataflashsabot> I think we might be a figment of Gaeel's twisted imagination...

*

Offline Krumel

  • 33
  • 0
  • One can be dividided by Zero!
    • View Profile
Re: encryption
« Reply #3 on: June 24, 2009, 20:26:34 »
I'm not sure what the XOR does

XOR is a boolean operation. It returns false if both booleans are the same and true if not.
If it's used on an integer (or byte) then it does the operation on every bit of the number.

Example:
5 XOR 6 = 3
now in binary:
110 XOR
101 =
011


Re: encryption
« Reply #4 on: June 24, 2009, 21:56:03 »
I think it's a bit unsafe, because the key is a byte. So anyone who wants to decrypt, "just" needs 256 tries.
Indeed.
Lurk more.

*

Offline rrc2soft

  • 191
  • 8
    • View Profile
Re: encryption
« Reply #5 on: June 25, 2009, 00:16:11 »
I'm working on an encryption program, and part of the algorithm is:
(k=one byte of key)
(m=one byte of message)
is the algorithm
Code: [Select]
result = ((m - k) XOR k) + k insecure? in other words, is it possible to get m without k?

If you are creating an encryption algorithm because you are going to use it (not for any competition / fun / etc), follow this advice: Use any existing standard. Being it AES, or any of the new (and available as open source) stream algorithms from eCRYPT. Creating your own encryption algorithm is both pointless and very dangerous (This very important company did create their own cryptographic stuff without asking for feedback to the research community... and look at what happened)


*

Offline TechnoGeek

  • 238
  • 0
  • My new project, Notroid
    • View Profile
Re: encryption
« Reply #6 on: June 25, 2009, 17:52:21 »
actually, I'm missing a very important part of the algorithm (sorry!)
the correct one is:
result = ((m-k) XOR k) + k) XOR previous_unencrypted_m
where the previous unencrypted m makes it an asymmetrical algorithm, needing a 1-byte initialization vector (possibly derived somehow from the passphrase that generates k)

and this is mostly for challenging myself and my abilities, but I may use it to scramble variables in a data file...
Spoiler: Technogeek's Signature (click to show/hide)

*

Offline J

  • Information leaking
  • 242
  • 12
  • I have a chicken on my head.
    • View Profile
    • Greywool
Re: encryption
« Reply #7 on: June 27, 2009, 18:53:38 »
Removed half of the topic for not having anything at all to do with the topic. Seriously, if you don't have anything to say, just don't post! :moody:

Ontopic:
I don't think adding the previous m (XOR 0 on the first character?) would really add to the security, compared to not including it. It would still just need the 256 attempts described earlier (to break the first character). The rest would follow along. :) I believe a longer key would have a better chance of increasing the security.
"flipping around like an idiot" -- Paula

*

Offline TechnoGeek

  • 238
  • 0
  • My new project, Notroid
    • View Profile
Re: encryption
« Reply #8 on: June 27, 2009, 23:40:48 »
Ontopic:
I don't think adding the previous m (XOR 0 on the first character?) would really add to the security, compared to not including it. It would still just need the 256 attempts described earlier (to break the first character). The rest would follow along. :) I believe a longer key would have a better chance of increasing the security.

the key is actually different for each part of m, it's a long cycle of characters that are derived from a passphrase.
Spoiler: Technogeek's Signature (click to show/hide)