![]() |
|
#1
|
|||
|
|||
Encryption implementation issueHi there,
I am not very experienced with C/C++ but I have a project that requires some C++ code. What I want to do is get a basic encryption module working. I don't want to rely on huge libraries such as crypt++ or mcrypt or anything like that, I just want a simple encryption algorithm in a self-contained block of code. The encryption algorithm I have selected is called the Tiny Encryption Algorithm or "TEA". It is a very simple block cipher that accepts a 128-bit key. All I want to do is to create simple C++ wrapper functions to encrypt and decrypt data. The example attached *looks* like it is working properly. It encrypts a block of text and then decrypts it successfully. As you'll see, the strings are casted to unsigned longs so the encryption algorithm can do its thing. However, what I need to be able to do is access the encrypted text as either a char or string so I can return it to my application. When I cast it to a char, I get a string which is much less than the length of the plain text string. This is wrong, they should have identical lengths. What I think is happening is that when I cast back to char from the unsigned long, any bytes that would cast back to "non-printable" characters are being lost. Is that likely? Do I have to perform some sort of encoding, like Base64 on the byte stream so it can be successfully output as a string? Please bear in mind that in this case, - I cannot use platform-specific libraries - The output must be of type string or char, I can't use the standard file libraries. CPP / C++ / C Code:
|
|||
|
#2
|
|||
|
|||
|
Quote:
Now, the function strlen looks at the sequence of chars, starting with the address that you give it, and counts chars until it finds a char with value of 0. If the encrypted data has any single byte with value 00, strlen thinks that's the end of the string. Say, for example an unsigned long has value 0x12003456. Strlen would stop at the 00, with a value equal to however many bytes it has seen up to that point. In other words, this use of strlen() is not appropriate. (It might give the "right answer", but you shouldn't count on it.) As a matter of fact, I compiled and executed your code and got 311 for the input text and the encrypted text. (Borland bcc32, Microsoft Visual C++, gnu g++ on my Windows XP box and g++ on my Linux box). Dave |
|
#3
|
|||
|
|||
|
Thanks, Dan, that makes perfect sense. I completely overlooked the null byte issue. I checked and the encryption code is definitely writing null bytes so this explains it.
It's interesting that code compiled and ran successfully on your systems, I will try a different compiler to check this. I have been using Codewarrior 8 on Mac OS X (which is needed for this particular project). |
|
#4
|
|||
|
|||
|
Quote:
(It's Dave) I just now did a copy and paste from your original post, and I have run your original code on two different PCs. The Windows compilers that I used are Borland bcc32, Microsoft Visual C++, and gnu g++. On my Linux box I uset gnu g++. The bytes written from your encryptedText array are identical for all. (304 non-zero bytes from encrypt(), followed by "octopus", in the last seven). I am looking for system-dependent behavior, and I realize that I don't know anything about Mac systems. It occurs to me that when you cast (char *) to (unsigned long *) it doesn't change the bytes that are in memory, but the values used in encrypt() will be different for little-endian systems and big-endian systems. What is the size of your unsigned long types? (Mine is 4, which is consistent with what I expect the behavior of your program to accommodate.) Is your system big-endian or little-endian (mine are little-endian, as are all systems based on Intel/AMD Pentium/Athlon, etc., 32-bit systems). Don't know? Try the following: CPP / C++ / C Code:
Note that this is a valid C program and a valid C++ program, so compile it as either. The results on a given system will be the same. Let me know what you discover. Dave |
|
#5
|
|||
|
|||
|
Sorry Dave, I don't know where I pulled "Dan" from.
Here's the output of your code: Code:
As I suspected, the Mac is big-endian. Quote:
Ah, that's interesting. I will have to investigate this. |
|
#6
|
||||
|
||||
|
Quote:
Motorola processors (like those used in Mac and, I think, IBM 390) use "Big Endian" byte order. Regards, Luci __________________
Please read these Guidelines before posting on the forum "A person who never made a mistake never tried anything new." Einstein |
|
#7
|
|||
|
|||
|
Quote:
When I took your input string and flipped the bytes (so that the array of unsigned long is presented to the encipher() function like they would be in a big-endian system), and I flipped the bytes in your key, I got some zero bytes in the encrypted text. Other inputs and other keys might, or might not, give 00 bytes in little-endian or big-endian systems, so it's never OK to use strlen() to discover the length of the encrypted data. Now, since you can't use strlen() to determine the length of the encrypted text, you the decipherer must know the length somehow. Note that, since your encrypted text could have a number (between 0 and 7) of unencrypted bytes at the end, you can't simply use the file size of the encrypted text. So you must tell the length to the decipherer (either by separate communication, or, maybe putting the length somewhere in the file). Of course the decipherer must also know the key. It does point out an interesting thing: if you encode on a big-endian system and decode on a little-endian system, one or the other must flip the bytes when using a method that casts (char *) as (unsigned long *). The decrypter must also must apply the decrypt algorithm consistent with the endianness of the encrypton. Also, note that not all systems have 32-bit unsigned longs. So that convention would also have to be included in the specification. Are we having fun yet? I've learned a few things today, so I have to say it's a Good Day. Regards, Dave Last edited by davekw7x : 02-Sep-2004 at 13:07.
|
Recent GIDBlog
Programming ebook direct download available by crystalattice
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| PHP/MySQL coding issue | cmarti | MySQL / PHP Forum | 3 | 26-Jul-2004 09:01 |
| Help with binary files (encryption?) | pablowablo | C++ Forum | 6 | 28-Apr-2004 23:47 |
| setiosflags issue | dcj1978 | C++ Forum | 1 | 08-Aug-2003 06:16 |
| Php bbcode issue | Caged | MySQL / PHP Forum | 3 | 06-Aug-2003 19:55 |
| Loading issue | jrobbio | Websites Reviewed Forum | 4 | 15-Jan-2003 06:36 |
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The