Clan x86
Technical (Development, Security, etc.) => General Programming => Topic started by: Joe on June 24, 2006, 07:38:35 pm
-
I think this one is actually secure, because as far as I can see, it's impossible to decrypt it without the key, and you can't guess the next byte of the message without knowing the one before it. I can explain it if you have a question, but for now, here's the code:
public class Xorcryption
{
/**
Testing method
*/
public static void main(String args[])
{
String message = "This is an test message.";
String key = "00112233445566778899";
printStringHex(message); // Hex before encrypting
message = xorEncode(message, key);
printStringHex(message); // Hex after encrypting
message = xorDecode(message, key);
printStringHex(message); // Hex after decrypting
System.out.println(message);
}
/**
Prints a string in hex.
*/
private static void printStringHex(String s)
{
for(int i = 0; i < s.length(); i++)
{
System.out.print(Integer.toHexString((int)s.charAt(i)) + " ");
}
System.out.println();
}
/**
Encodes a string
@param data Data to encode
@param key Key to encode with
*/
public static String xorEncode(String data, String key)
{
byte m_cData[] = data.getBytes();
byte m_cKey [] = key .getBytes();
int keyPointer = 0;
for(int i = 0; i < m_cData.length; i++)
{
m_cData[i] ^= m_cKey[keyPointer];
keyPointer += m_cData[i];
keyPointer %= m_cKey.length;
}
return new String(m_cData);
}
/**
Decodes a string
@param data Data to decode
@param key Key to decode with
*/
public static String xorDecode(String data, String key)
{
byte m_cData[] = data.getBytes();
byte m_cKey [] = key .getBytes();
// This was a little interesting to code, because by the time
// we increase the keyPointer, what we have to increase it by
// is already destroyed by the line above it. Therefore, we
// have to set keyPointerAdd before we decrypt the byte that
// holds what's added to the pointer.
int keyPointer = 0;
byte keyPointerAdd = 0;
for(int i = 0; i < m_cData.length; i++)
{
keyPointerAdd = m_cData[i];
m_cData[i] ^= m_cKey[keyPointer];
keyPointer += keyPointerAdd;
keyPointer %= m_cKey.length;
}
return new String(m_cData);
}
}
Note: If you're actually going to use it, you can exclude main and printStringHex and use it all staticly (is that a word?).
-
String message = "This is an test message.";
Typo!! "This is a test message."
:P
-
My bad. Originally it was "This is an encoded message", but when I thought about it, I knew someone would make fun of me for still calling it encoded after decoding it, so I changed it to test, totally oblivious to the fact that I had "an". Yet another reason why the rules of English are horrible, IMO.
-
I think this one is actually secure, because as far as I can see, it's impossible to decrypt it without the key, and you can't guess the next byte of the message without knowing the one before it. I can explain it if you have a question, but for now, here's the code:
Still wrong. This sort of encryption is only "secure" in an implementation known as a "one-time pad," in which, these conditions are true:
1) The key is equally or greater in length to the text to be encrypted.
2) The key is only used once
3) The key is truely and totally random
4) The key is kept secret
-
Well, then all he needs to do is feed the key something from, for example, an SRP key exchange authorization (like WoW does) and he has a truly random, truly secret key. The key changes at every authentication attempt even though you're validating the same password.
Incidentally, that's how WoW encrypts its realm server communication.
-
Well, then all he needs to do is feed the key something from, for example, an SRP key exchange authorization (like WoW does) and he has a truly random, truly secret key. The key changes at every authentication attempt even though you're validating the same password.
Incidentally, that's how WoW encrypts its realm server communication.
And to generate the key in a fashion that makes it as long as the input text.
-
Well, then all he needs to do is feed the key something from, for example, an SRP key exchange authorization (like WoW does) and he has a truly random, truly secret key. The key changes at every authentication attempt even though you're validating the same password.
Incidentally, that's how WoW encrypts its realm server communication.
And to generate the key in a fashion that makes it as long as the input text.
Well, you could modify that funny sha-interleave thing that SPR does to increase key length. I don't know what that would do for you, if anything.
Still, even a 40 byte key would be extremely hard to break if it was never exchanged directly over the wire. I don't think to have secure communications you need "perfect secrecy," like the one-time pad suggests.
-
Here's my take on this: All encryption that has it's keys transfered over the wire and then understood on the other end can be cracked in some way or another. It's just a matter of making it difficult.
-
Still, even a 40 byte key would be extremely hard to break if it was never exchanged directly over the wire. I don't think to have secure communications you need "perfect secrecy," like the one-time pad suggests.
Finding redundancies in the encrypted data from using a short or constant key is a negligible task for the right person.
Here's my take on this: All encryption that has it's keys transfered over the wire and then understood on the other end can be cracked in some way or another. It's just a matter of making it difficult.
Thank you for stating the intuitively obvious. ;)
-
Yeah, XOR-encryption is useful if fast communication is needed. But like any symmetric-key cipher, the trick is finding the proper key-length and exchanging the key in a secure mannger. With my remote-control client/server, I use SRP then feed that key into AES, which is basically the same idea.
I'd still stick with a real cipher like AES or 3DES instead of writing my own, though. I wrote a little wrapper class around Java's Cipher class. It's hidden in my RemoteControl code that I posted elsewhere, but I can re-post it here if anybody is interested.
-
Still, even a 40 byte key would be extremely hard to break if it was never exchanged directly over the wire. I don't think to have secure communications you need "perfect secrecy," like the one-time pad suggests.
Finding redundancies in the encrypted data from using a short or constant key is a negligible task for the right person.
Like people who have had Number Theory ;)
-
Like people who have had Number Theory ;)
:D