> From: owner-openssl-us...@openssl.org On Behalf Of Rafel Coyle
> Sent: Tuesday, 17 February, 2009 21:54
> To: openssl-users@openssl.org
> Subject: Re: Decryption does not yield the same as Encryption
>
>
> I sent this snippet out a few days ago, but I haven't received an
> adequate response. I am encrypting and base 64 encoding per the code
> below. I am using 15 digit Amex numbers. On some numbers I get a valid
> encryption and decryption and on others my decryption ends up losing the
> last character. Can anybody see anything improper in the coding below.
I assume you mean the code snippet in this post combined with the prior one
in a sensible fashion. And you mean Amex numbers represented as 15 ASCII
digits=chars=bytes -- which is slightly wasteful, you can easily compact
them to 8 bytes in BCD. And I assume you are somewhere generating random
or at least unique IVs, as is necessary for CFB to be reasonably secure.
> Should I be appending a carriage return on the encoding? Apparently the
> encryption is returning a binary string. Am I properly encoding a
> binary string? Can someone help me for a fee or whatever is necessary
> to solve this problem?
>
Yes, any modern encryption, including Blowfish cfb64, will return
effectively random binary data, which is not necessarily a string.
If you need to handle that data in a context designed for strings,
and especially printable strings, like email, some databases, etc.,
you need to encode it, and base64 is a very common encoding for this.
(There are other encodings you could consider if this is entirely
your own system. But if you need to interoperate with other existing
systems you must use the/an encoding they support, and base64 likely
is that; and even if you need to interoperate only with new or modified
systems developed by others, using a widely understood and implemented
encoding is usually wisest, and base64 also is that.)
If you want the base64 encoding in a C string, then
BIO_get_mem_ptr( b64, &bptr ); /* reinstated */
> buff = malloc(bptr->length + 1); /* as modified */
memcpy (buff, bptr->data, bptr->length); /* reinstated */
> buff[bptr->length]=0; /* as modified */
is indeed the correct way to do that. (Except you should add a
check that the return value of malloc, here buff, is non-null
before using it. A small allocation like this should 'never'
fail on a reasonable system, but if you ever get into a situation
where it does, some reasonable error message or code is better
than a mysterious crash, or even worse undetected corruption.)
Whether you add any suffix (and/or overhead) to the base64 encoding
depends on the application(s) in which you are using it. The method
you are using, of a BIO_f_base64, will add a C newline (NL aka LF)
at end, and PEM-compatible intervals (which won't occur for
your very short data), unless you set BIO_FLAGS_BASE64_NO_NL,
and similarly will expect and skip it on input=decoding.
On some systems (notably Windows) a C newline output to a text file
is converted to the system convention of CRLF, and conversely on
input. Most Internet formats use CRLF for linebreak so you must
do the same translation, explicitly if necessary. I don't know of
any applications that use just CR, but it's technically possible.
Other kinds of overhead are also possible, like HTML/XML tags.
For small fixed data like this you don't really get any benefit
from going through BIO; you can just call EVP_{En,De}code* directly.
Or code your own b64; it's only about 10 lines for in-memory encoder,
and maybe 20 for in-memory decoder with simple error handling. (For
this data you don't even need '=' padding, but I would still do it;
it isn't much work and might easily become needed in the future.)
Since CFB is a stream cipher, the (binary) ciphertext length
is the same as the cleartext length, here always 15; and the
base64 encoding of 15 bytes is always 20 characters. You might
add checks that your encoding produces 20 chars (excluding any
suffix/overhead, such as NL) and your decoding receives 20 (ditto)
and returns a result of 15 even BEFORE you decrypt it.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
