Nifflas' Support Forum
Being Creative => Creativity Support => Topic started by: TechnoGeek 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 result = ((m - k) XOR k) + k insecure? in other words, is it possible to get m without k?
-
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.
-
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...
-
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
-
I think it's a bit unsafe, because the key is a byte. So anyone who wants to decrypt, "just" needs 256 tries.
Indeed.
-
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 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 (http://www.ecrypt.eu.org/stream/). Creating your own encryption algorithm is both pointless and very dangerous (This very important company (http://www.nxp.com/) did create their own cryptographic stuff without asking for feedback to the research community... and look at what happened (http://www.schneier.com/blog/archives/2008/01/dutch_rfid_tran.html))
-
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...
-
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.
-
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.