Hi Muadzafri,
> first question is, the KEY_LENGTH. Can I just put any number from
> 1-32 to define the key length?
The scheme defines the key size. I prefer to use the class' constants:
// Key and IV setup
byte key[ CryptoPP::AES::DEFAULT_KEYLENGTH ];
byte iv[ CryptoPP::AES::BLOCKSIZE ];
or
byte digest[CryptoPP::SHA256::DIGESTSIZE];
> second is what is the 0x0,0x1,0x2,0x3,0x4,0x5...
Poetic initialization. I prefer the following for constructor or
initialization routine in a DEBUG build:
memset( key, 0x00, CryptoPP::AES::DEFAULT_KEYLENGTH );
memset( iv, 0x00, CryptoPP::AES::BLOCKSIZE );
In a release build, you would probably want something a bit more random.
Generate the keys using AutoSeededRandomPool:
CryptoPP::AutoSeededRandomPool rng;
for( i = 0; i < CryptoPP::AES::DEFAULT_KEYLENGTH; i++ ) {
key[i] = rng.GenerateByte());
}
for( i = 0; i < CryptoPP:AES::BLOCKSIZE; i++ ) {
iv[i] = rng.GenerateByte());
}
> i did some timing function to the code that I'm running to see how
> fast compared to other algorithm like DES, TWOFISH ...
> ...
> Either I used KEY_LENGTH 32,16,8 for blowfish...
The speed should stay the same - it is not generally (some hand waving here)
dependent on key or iv length or material.
What will happen is the key is too short, just right, or too long. Just
right and too long will produce desired results:
#define KEY_LENGTH 64
byte key[KEY_LENGTH] = { 0x0, ..., 0x0 };
Now, suppose you are using this with AES. AES::DEFAULT_KEYLENGTH is 16. So
you have extra key material (64 - 16) or 48 bytes which is not used.
But too short will get you in trouble:
#define KEY_LENGTH 8
byte key[KEY_LENGTH] = { 0x0, ..., 0x0 };
Now, suppose you are using this with AES. AES::DEFAULT_KEYLENGTH is 16. So
your AES Encryption or Decryption object will consume your desired 8 bytes,
and 8 bytes of garbage (whatever is laid out after key in you .DATA
segment). DEBUG builds (in Microsoft's environment) will generally produce
desired results. However, Release builds will not (due to certain
initializations in DEBUG builds).
> Isnt it supposed to be if the keylenght is extend, ...
Also, larger key lengths do not necessarily add security. For example, RIPE
hashing. There is no more security when using a 320 bit key versus a 160 bit
key.
A little more reading on the algorithms, and some more C++ experience should
be very useful for you.
Jeff
----- Original Message -----
From: "Muadzafri Makhtar" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, November 10, 2005 12:31 AM
Subject: understandting keylength problem
> hi guys,
>
> i'm a newbie in cryptogrphy programming. i got this code example in a
> previous posting in the mailing list, but i could not find it back
> anywhere by using the search tool in the archieve. I'm currently
> playing around with some symmeteric encryption like blowfish in trying
> to understand how they work. But the thing is this is part of the
> code that i'm being tried to study but could no fully understand:
>
> #define KEY_LENGTH 16
>
> byte key[KEY_LENGTH]= //32bytes
> {0x0,0x1,0x2,0x3,0x4,0x5,0x6,0x7,0x8,0x9,0xA,0xB,0xC,0xD,0xF};
>
> byte iv[16] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
>
> CryptoPP::BlowfishEncryption enc(key, KEY_LENGTH);
> CryptoPP::CBC_CTS_Encryptor cbcEnc(enc, iv);
>
> first question is, the KEY_LENGTH. Can i just put any number from
> 1-32 to define the key lenght?
>
> second is what is the 0x0,0x1,0x2,0x3,0x4,0x5 or sometimes 0x48, 0x93,
> 0x46, 0x67, 0x98, 0x3D, 0xE6, 0x8D all about? is it specific to lenght
> of KEY_LENGTH defined earlier? how to create those number for the
> KEY_LENGHT?
>
> i did some timing function to the code that i'm running to see how
> fast compared to other algoritm like DES, TWOFISH etc2. But the
> problem is when i changed the KEY_LENGHT from 32 to either 16, 8 or
> anynumber, the time recorded is still the same. Either i used
> KEY_LENGHT 32,16,8 for blowfish it just giving out the same timing
> results. Isnt it supposed to be if the keylenght is extend, then the
> encrypting time should be extended to?
>
> hope you guys can give some enligtment..
>
> thanks in advance..
>
> japp.
>
