> From: owner-openssl-us...@openssl.org On Behalf Of Brian Lavender
> Sent: Wednesday, 30 September, 2009 03:28
> To: openssl-users@openssl.org
> Subject: Re: Encrypting 32/64 bit integers
>
> On Fri, Sep 18, 2009 at 01:59:12PM -0700, musikit wrote:
> > 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.
>
> You could just xor the bits with the key.
>
As already said, very bad idea.
> >
> > 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?
>
> I would have to look at the specs for Triple DES, but I
> believe it is a block cipher, so it will always be a multiple
> of 128 bits or whatever its block size is.
>
Triple DES (officially TDEA, it never was a separate standard
and now isn't a formal standard at all) is indeed a block cipher,
but its blocksize is 64. Since the OP was encrypting variable
length strings with a block cipher, they were undoubtedly using
(perhaps by default) padding, which causes the expansion. (If
a value is already a full block(s) padding adds another block.)
The OP should already have been seeing this expansion for strings.
And, no, you can never ignore part(s) of a block mode ciphertext.
You can construct a stream cipher from a block primitive,
using modes like CFB, OFB, and CTR, and by now maybe more.
Then you have a stream cipher. But it will need an IV,
which (also) effectively expands your ciphertext.
OTOH, so does CBC if done properly.
Modern (i.e. computer) ciphers in modes like CBC-pad can handle
data of any length and any content (i.e. binary 'bytes').
That includes 32 or 64 bit integers or anything else.
However a simple API like the one the OP indicated may have
trouble *passing* such data. In particular if you use
Encrypt_string (u_char * from, u_char * to)
... Update (..., from, strlen(from)) ...
to determine the amount of input data, that DOESN'T work
for integers, or floats, or anything but strings, and this
is a general property of C not just for crypto.
You need to pass the length explicitly, or have some other
way to determine it. One simple but verbose way is just
to have separate routines:
Encrypt_2bytes (u_char * from, ...)
... Update (..., from, 2)) ...
Encrypt_4bytes (u_char * from, ...)
... Update (..., from, 4)) ...
etc. Many other approaches are possible.
But remember that every item encrypted separately is padded
separately, and for many small items that causes much expansion.
You might prefer to pack multiple items into a struct, or
concatenate their representations into a contiguous buffer,
and encrypt that (and then decrypt and unpack etc.) Two standard
ways of doing this are XDR and ASN.1, or you can invent your own.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
