Printable View
hi, I dont no much (well, abosolutely nothing) about string manipulation, and how exactly encryption works, I was wondering if some one on here could give me a few starters. I dont need something really complicated at the moment, just the basic starting points of encrypting...
:)
The easiest form of encryption is just doing a simple XOR operation. This is due to the principle that if you XOR a string with some key (key can be any value), and then XOR the result of the first operation with the key again, you will get your original string.
Now XOR is not very good if security is a main desire, because it is easy to break that encryption. It is a good place to start if you are just starting to learn encryption techniques though.
>Now XOR is not very good if security is a main desire
If you really believe this then you should do some research on one time pads.
Prelude seems to have it out for you. :D
I tried a method once that involved sine and cosine. The result is that characters are raised or lowered in ASCII value depending on their position in the array. I never got far with it though because I lost interest in it.
One other thing to do is to swap characters. Say swap every other second or third pair (or use sine and cosine to determine the pair swapped). ;)
one time pads are good encryption, but horrible security. The entire security mechanism surrounding one time pads relies on the fact that the key is kept secret. In practice, this is very hard to do, and that is why you dont see it in use in cases where security is essential. A prime number cypher, or MD5 is far better security wise.
Well, the problem with one time pads is that the key is unwieldy and difficult to generate (unless you have a true "random" source), because even with good random number generators (PRNGs), after a long enough time, some of the statistical properties may break down making it easier to exploit biases ("easier" being a very relative term). A one time pad is very secure, though.
And, you still use secret key ciphers in many encryption schemes. The most common one (that I have seen) generates a key for a secret key cipher, encrypts the data with that, and then encrypts the key with a public key algorithm. Often, a digital signature is added to alert the receiver if the data was in any way modified during transmission (either intentionally or otherwise), and/or verify the identity of the sender. It has been a while since I did much with crypto, but if memory serves me, MD5 is actually a one way hash, so you wouldn't actually encrypt your data with it, but might use it in the signing process.
Some algorithms off the top of my head:
Private key: Twofish, Rijndael (AES), DES, Blowfish, RC6
Public key: RSA (elliptic curve crypto is a fun one to look at too)
One way hash: SHA, Tiger, RIPE-MD
Yeah, MD5 is one way. Its main use (as relates to security) is for password validation. It's nice because this way servers aren't actually storing your password on the server.
>one time pads are good encryption, but horrible security.
Oh, I see. This is a classic case of the vague notion of "security". The more I participate in threads that talk about security, the more I despise the word. We should be very specific about what kind of security and in what context. :)
Compression would be one way to do simple encryption (security-wise, not very good) :) I just wrote a Huffman 'library' a short while ago (4 whole functions! Woohoo!), and I assure you it's very illegible to the average naked eye if that's what you're aiming for. If you're trying to learn to encrypt just for the heck of it though, I have nothing to input.
best encryption combines both an algorithim and a compression sceem,
it helps to reduce patterns in the file, in return makes it difficult to
crack it.
also, if in your code there is a easy way to see how to decrypt it
correctly, then its not good because anyone can get a decompiler
and see the code, therefore eliminating however good you
thought it might be.
right, at a minimum, an encryption scheme should be difficult to crack even when the algorithm is supplied.Quote:
Originally Posted by JarJarBinks
yea but i mean for simple encryption such as replacing letters, or
just adding numbers to change the ASCII value, that kind
of thing, would make it easy to know what you did or how
it was applied to your file.
my very first encryption program, could of bene cracked by doing
that, the one im currently working on wouldnt be nearly
that easy, but we will see.
Would you think this is secure? Sender and receiver could be on the net or a file (if steps 2&3 are left out).Quote:
Originally Posted by Prelude
1. Sender and receiver both know a users passwords MD5-hash (thats the only secret part).
2. Sender sends receiver a random integer, receiver rehashes the users password hash with that integer and sends it.
3. Sender does the same and compares. If match, actual message is transmitted.
4. Sender and receiver both increase the exchanged int by one (or start at one if 2&3 are left out).
5. Both rehash the original password hash with the new int.
6. Apply this hash via XOR on the first 16 byte (MD5 hash-len) of the message before sending/after receiving it.
7. Go back to step 4 until entire message has been streamed.
That is what I came up with for a simple filetransfer protocol. The MD5 function should produce a completely new hash for each used integer along with a random part which is the original password hash, so the keylen should be about MAXINT * 16 bytes.
Take a look at a cryptography FAQ and another overview.Quote:
just the basic starting points of encrypting
The entire (almost) security mechanism surrounding any strong encryption used nowadays relies on the fact that some key is kept secret.Quote:
The entire security mechanism surrounding one time pads relies on the fact that the key is kept secret.
Here is a simple example of using the XOR encryption mentioned above. It asks for a string to be encrypted, then asks for a key to be used to encrypt the data. It then displays the original string, the encrypted string and the decrypted (matching the original) string. This is only meant as a very basic example to show how it might/could be done (so no flames about it being pathetic/unsecure or whatever please).
Something I'd like to know... why the heck isn't there some kind of a std::exclusive_or<> function adapter? Seems it would be handy to have.Code:#include <string>
#include <iostream>
#include <algorithm>
#include <functional>
template<typename T>
struct exclusive_or : public std::binary_function<T,T,T>
{
T operator() (T lhs, T rhs) const
{
return lhs ^ rhs;
}
};
int main()
{
std::string data, key, temp;
// Get string and key from user
std::cout << "Enter string to encrypt: ";
std::getline(std::cin,data);
std::cout << "Enter key: ";
std::getline(std::cin,temp);
// Ensure key is at least as long as data to be encrypted.
// This is needed because of the transform call below
key = temp;
while( key.length() < data.length() ) key+= temp;
std::cout << "Original string: " << data << std::endl;
// Encrypt string and output
std::transform(data.begin(),data.end(),key.begin(),data.begin(),exclusive_or<char>());
std::cout << "Encrypted string: " << data << std::endl;
// Decrypt string and output using same procedure
std::transform(data.begin(),data.end(),key.begin(),data.begin(),exclusive_or<char>());
std::cout << "Decrypted string: " << data << std::endl;
return 0;
}