hello friends, lately I've been reading about one time pad and read somewhere that people usually use XOR in order to encrypt the message
if we use caesar cipher do we get a more secure encryption? or again it's the same thing? I mean, if the "attacker" finds out the key, then they won't have a problem finding out the encrypted message, or not?
I think I'm confused, what's the best way to encrypt a message using one time pad? is XOR the best way to go?
thanks in advance
They're pretty much the same: ceasar shift is just adding, and xor is like adding but ignoring the carry for all bits (ie, 1 + 1 => 0 but without "carry 1"). With that said, it is certainly possible that xor gives a slight performance boost due to the lack of carries, but I can't confirm that.
Using caesar cipher might throw the attacker for a loop should they get a hold of the key, considering the prevalence of xor, but if the attacker got hold of your key you probably have bigger things to worry about.
Last edited by bernt; 09-14-2010 at 04:59 PM.
Consider this post signed
XOR and Caesar are different ciphers, which encipher plaintext using a key. One-time pads are used in conjunction with a cipher to enhance security. A one-time pad is a series of randomly generated keys for a cipher. Each character in plaintext is enciphered with the next key given by the pad. This becomes secure because the characters are enciphered with different keys, rather than the same one, and makes cryptanalysis much more difficult (if close to impossible). A copy of the original pad is needed in order to decrypt the ciphertext. Where you have to be careful, is making sure the one-time pad is secured where no-one else can get it, but that the proper recipient has to have a copy in order to decipher/encipher messages.
Theoretically, which cipher is used (XOR, Caesar, or other), shouldn't matter with a one-time key, but XOR is more likely to be used (computationally faster than Caesar).
Last edited by neandrake; 09-14-2010 at 05:01 PM.
Environment: OS X, GCC / G++
Codes: Java, C#, C/C++
AOL IM: neandrake, Email: neandrake (at) gmail (dot) com
There's no point in using anything other than XOR, because if you did, the results would be the same as using XOR with a different pad. In other words, suppose you have Pad[0] and you use Caesar to encrypt. This is the same as having some other Pad[1] and using XOR to encrypt. Since the pad doesn't matter, so long as it's truly random, the particular method of combining key and plaintext bits also does not matter.
Using a non-standard mixer on the off chance that somebody will obtain the pad, is kind of like hoping your Scooby Doo underwear will serve as that last line of defense against a bullet.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
excellent point brewbuck
Environment: OS X, GCC / G++
Codes: Java, C#, C/C++
AOL IM: neandrake, Email: neandrake (at) gmail (dot) com
the problem that I have with XOR is that the encrypted message has strange characters
for example for something like
char data[] = "THIS IS SECRET";
char key[] = "XVHE UW NORGDZ";
I get an encrypted message that is like x x
really strange characters, of course if I just save it somewhere and then try to reencrypt the data(decrypt if using XOR) then the secret message appears
after searching online I saw many encrypted messages that had sense though, they were like "a28c93uiu2ajse" and stuff like that, at least you could read the characters, and maybe they didn't use XOR maybe they used another better method? I'm not sure
You can base64 the binary message that is the result, or display it has a hexadecimal value (ie. every byte displayed with two characters). Base64 is more compact (3 characters from 2 characters in stead of 4 characters from 2 characters) but also much harder to implement.Originally Posted by nik2
So simply display each byte as hexadecimal value, that ought to do the job.
thanks, I did this and worked great
Nothing beats the one time pad, much less so the caesar cipher; pattern analysis is often used effectively against the latter, whereas the former is theoretically unbreakable (in the limited sense that the matter of key distribution has been conveniently disregarded).
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
