You are doing it very very wrong.
It has been known at least since the 1970s that trying to use ASCII
letters (with or without parity) directly as the encryption key is a
bad idea, because human entered text has only about 1 to 2 bits of
entropy per letter and even machine generated random text contains at
most 6.5 bits per character, while the security of the encryption
algorithms requires the full 8 bits per byte of entropy.
There are lots of well thought out standard methods to use a human
entered string as the most secret part of the input that determines
the full key, and OpenSSL contains implementations of at least two
of them. Such algorithms are called Password-Based-Key-Derivation
Functions and generally work with an almost unlimited password length
(passwords longer than 500 million letters can hit some limits, but
who would memorize such a long password and then type it in by hand?).
You should also be aware that the key length is different for different
algorithms, and EVP_MAX_KEY_LENGTH constant is simply the largest of all
the key lengths of all the algorithms included, which is obviously NOT the
key length of any particular algorithm you may choose. There is an
EVP function that returns the (constant) key length of the algorithm you
use, just in case you didn't already know (like if the code can select
between different algorithms). Code compiled against any given version
of OpenSSL can safely assume that the length returned by that EVP function
will be at most the value of EVP_MAX_KEY_LENGTH from that OpenSSL version,
nothing else.
On 26-03-2013 20:32, redpath wrote:
Well I discovered one thing this constant EVP_MAX_KEY_LENGTH changed when
using FIPS
from 32 to 64. The story is
I am using 0.9.8 and this constant to assure the password a person may use
by a user is
not larger than this for AES128 ciphering as undetermined results happen on
other platforms in other words
I may cipher a file on one platform and decipher on another and if my key I
used was greater than
this constant I have issues (it don't work). Well makes sense there is a
limit in password size.
Well I was on Redhat linux and it had 1.0.x openssl and I had to define FIPS
to use an ECDSA curve I was using to sign things. This constant
EVP_MAX_KEY_LENGTH changed in size and when a user decided to
use their password which was well above 32 bytes it accepted all of it and
tried to use it to decipher something that had been ciphered a while back;
well it did not work.
So we have our own constant now and only accept passwords that are 32 bytes
long though you can
type in as much as you want we will only use 32 bytes.
Also I hope the openssl 1.0.x is on all platforms including iOS.
Well thats my experience.
--
View this message in context:
http://openssl.6102.n7.nabble.com/0-9-8-vs-1-0-x-tp44547p44549.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
<call:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
