Hi Peter,
> so we ran this with a 64 bit int and noticed that 128 bits comes out.
> can we safely ignore the other 64 bits? why are we getting 128 bits out?
It depends on your choice of modes. Specifically on the padding
requirements accompanying the mode.
Modes such as ECB and CBC will pad to the block size. It due to
how/where the XOR occurs during processing of the sub-block. Modes
such as OFB, which operate the cipher in a stream like fashion, do not
suffer the expansion. Again, look at how the XOR is occurring on the
generated key stream.
Next, try encrypting '0 bytes'.
Jeff
On Mon, Sep 21, 2009 at 11:00 AM, Peter Wilkes <pwil...@choopa.net> wrote:
> sorry if this is being posted a 2nd time. i got an email stating it was
> rejected....
>
> hello,
>
> please forgive me as i am not an OpenSSL or encryption expert.
>
> i am already using OpenSSL to do encryption of strings and it works awesome.
> i do have a question about encrypting smaller amounts of data though.
>
> my code basically goes as follows
>
> Encrypt(datato, datafrom)
> {
> EVP_EncryptInit();
> EVP_EncryptUpdate();
> EVP_EncryptFinal();
> EVP_CIPHER_CTX_cleanup();
> }
>
> again works awesome for strings. however we are realizing there are
> sometimes we just want a 32 bit int or a 64 bit int encrypted and nothing
> else.
>
> so we ran this with a 64 bit int and noticed that 128 bits comes out. can we
> safely ignore the other 64 bits? why are we getting 128 bits out?
>
> we are using the TripleDES cipher.
>
> thank you.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-us...@openssl.org
> Automated List Manager majord...@openssl.org
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
