I'm working on a larger program, but have managed to isolate the problem in this small one. I am using GCC 4.4.5, and scanf seems to have a strange inconsistency.
Code:#include <stdio.h> int main() { unsigned char plaintextbuf[32]; printf("Enter plaintext: "); // input: f34481ec3cc627bacd5dc3fb08f273e6 scanf("%s", plaintextbuf); printf("\n%02x %02x\n",plaintextbuf[0], plaintextbuf[1]); // output: 66 33 return(0); }
Do you understand the difference between signed and unsigned?
Quzah.
Hope is the first step on the road to disappointment.
Why is it inconsistent? Doesn't it always output: 66 33?
66 and 33 are the hex ASCII values for 'f' and '3' respectively. I don't see anything inconsistent about it.
If you understand what you're doing, you're not learning anything.
f34481ec3cc627bacd5dc3fb08f273e6
How many characters does it have? If it has n, scanf arg needs to hold n+1,
+1 for '\0' byte that scanf will append
It is inconsistent, sorry, it printed out 00 33 before, strangely.
@quzah Unsigned variables use the sign bit as part of the value, making them able to support larger numbers, but can't do negatives as a result.
EDIT: When I write it more in the context of my program, it outputs 00 33, looks like that was working correctly, sorry.
The version above outputs 00 33 with "f34481ec3cc627bacd5dc3fb08f273e6" for the plaintext and "00000000000000000000000000000000" for the key.Code:#include <stdio.h> int main() { unsigned char plaintextbuf[32], keybuf[32], ivbuf[32], tmp[2]; unsigned char plaintext[32], key[32], iv[32] = {0}; int i = 0, y = 0; printf("Enter plaintext: "); scanf("%s", plaintextbuf); printf("Enter key: "); scanf("%s", keybuf); printf("\n%02x %02x\n",plaintextbuf[0], plaintextbuf[1]); return(0); }
Last edited by Wolf`; 03-01-2011 at 06:18 PM.
1) your plaintextbuff is too small ... you always have to have at least one extra slot in the array to hold the trailing 0 essential to C strings... so you need to make that bigger...
2) the letters you entered are stored according to their ascii values... The letter 'f' is actually stored as 0x66 (102 decimal) and the number '3' is stored as 0x33 (51 decimal)... it is outputting the correct values. Ascii Table - ASCII character codes and html, octal, hex and decimal chart conversion
So... your problem is?
My problem is, is that I believe my plaintext buffer is perfectly fine, seeing as arrays start at 0, and I am storing 32 characters, stopping at 31, leaving 32 for the NULL. And I know what hex is, above was a mistake. 00 33 is incorrect for f and 3, don't you think?Originally Posted by CommonTater
Did you even bother to read my post above?
Well at least you know what your problem is. Your problem is that you believe it is perfectly fine. Five people have told you you are wrong. You really need to learn how to ask questions the smart way. You didn't say anything about what your problem was ... at all. That's terrible when you're trying to actually get help.
Quzah.
Last edited by quzah; 03-01-2011 at 06:55 PM.
Hope is the first step on the road to disappointment.
No. You're allocating space for 32 items. For example:
char str[3]; // Allocate space for 3 chars
Now you have space for 2 input characters plus a '\0' to terminate the string. str[0] is an input char, str[1] is an input char, str[2] is the '\0'. str[3] is invalid, outside the bounds of the array.
If you understand what you're doing, you're not learning anything.
I see, thanks, works now.
Nope... It's not.
You are mistaking "the number of elements" for "the number of the element"...
It's ok, use your fingers... how many elements are there in an array numbered 0 to 9?
That's right... there are 10.
When you assign 32 elements, you get an array of 32 elements numbered 0 to 31. If you put 32 characters in it, the trailing null is out of bounds for the array and might even write itself into other variables causing a program crash.
You're free to ignore my advice but you will believe me the first time you go to print your string and your screen fills with page after page of garbage because the trailing null is missing.
It's not hex... it's ASCII... the American Standard Code for Information Interchange... Click the link I gave you, it displays a real nice chart.And I know what hex is, above was a mistake. 00 33 is incorrect for f and 3, don't you think?
The most likely reason you got 00 for your first slot is because one of your "it's ok there's an extra character in there" buffers overwrote the first byte of this one...
Since it looks like you're doing symmetric key encryption, there are a few things you need to watch out for regarding your encryption key and IV.
Unlike a string, the encryption key an IV are a fixed number of characters. How many depends on the encryption algorithm. For example, AES-256 uses a 32 byte key and a 16 byte IV. If you're reading in the key from the console and the string length is less than the key length - 1, you need to make sure the remaining bytes in the key are padded out to a known value.
If you read in the key for encryption in a separate place from the key for decryption and you fail to take the padding into account, you mysteriously won't be able to decrypt with the same key you encrypted with until you find out the uninitialized bytes aren't the same.
