DES's keyschedules.
I know these two should be separate, and I'll back out the DES changes if they
are deemed to be an error.
Note that there is a memory leak lurking in SSL somewhere in this version.
HP-UX in common in ./config). Note that for the moment of this writing
none of 64-bit platforms pass bntest. I'm committing this anyway as it's
too frustrating to patch snapshots over and over while 0.9.6 is known to
work.
Split private key PEM and normal PEM handling. Private key
handling needs to link in stuff like PKCS#8.
Relocate the ASN1 *_dup() functions, to the relevant ASN1
modules using new macro IMPLEMENT_ASN1_DUP_FUNCTION. Previously
these were all in crypto/x509/x_all.c along with every ASN1
BIO/fp function which linked in *every* ASN1 function if
a single dup was used.
Move the authority key id ASN1 structure to a separate file.
This is used in the X509 routines and its previous location
linked in all the v3 extension code.
Also move ASN1_tag2bit to avoid linking in a_bytes.c which
is now largely obsolete.
So far under Linux stripped binary with single PEM_read_X509
is now 238K compared to 380K before these changes.
reduce linker bloat. For example the
single line:
PEM_read_X509()
results in a binary of around 400K in Linux!
This first step separates some of the PEM functions and
avoids linking in some PKCS#7 and PKCS#12 code.
does not contain more bytes than the RSA modulus 'n' - it does not check
that the input is strictly *less* than 'n'. Whether this should be the
case or not is open to debate - however, due to security problems with
returning miscalculated CRT results, the 'rsa_mod_exp' implementation in
rsa_eay.c now performs a public-key exponentiation to verify the CRT result
and in the event of an error will instead recalculate and return a non-CRT
(more expensive) mod_exp calculation. As the mod_exp of 'I' is equivalent
to the mod_exp of 'I mod n', and the verify result is automatically between
0 and n-1 inclusive, the verify only matches the input if 'I' was less than
'n', otherwise even a correct CRT calculation is only congruent to 'I' (ie.
they differ by a multiple of 'n'). Rather than rejecting correct
calculations and doing redundant and slower ones instead, this changes the
equality check in the verification code to a congruence check.
SSL according to RFC 2712. His comment is:
This is a patch to openssl-SNAP-20010702 to support Kerberized SSL
authentication. I'm expecting to have the full kssl-0.5 kit up on
sourceforge by the end of the week. The full kit includes patches
for mod-ssl, apache, and a few text clients. The sourceforge URL
is http://sourceforge.net/projects/kssl/ .
Thanks to a note from Simon Wilkinson I've replaced my KRB5 AP_REQ
message with a real KerberosWrapper struct. I think this is fully
RFC 2712 compliant now, including support for the optional
authenticator field. I also added openssl-style ASN.1 macros for
a few Kerberos structs; see crypto/krb5/ if you're interested.
Add new extension functions which work with NCONF.
Tidy up extension config routines and remove redundant code.
Fix NCONF_get_number().
Todo: more testing of apps to see they still work...
application do that.
NOTE: there's no requirement for other UI_METHODs to avoid this kind
of loop. For example, a GUI UI_METHOD would probably check the
lengths of the answers from within instead of being constantly
redisplayed for everything that is wrong.
Implement UI controls. Current controls are the possibility to output
the OpenSSL error stack on the same channel from within UI_process()
and to check if the same user interface can be redone without being
rebuilt (this is often more a question of philosophy than
technicalities).
applications to use EVP. Add missing calls to HMAC_cleanup() and
don't assume HMAC_CTX can be copied using memcpy().
Note: this is almost identical to the patch submitted to openssl-dev
by Verdon Walker <VWalker@novell.com> except some redundant
EVP_add_digest_()/EVP_cleanup() calls were removed and some changes
made to avoid compiler warnings.
with arbitrary arguments instead of just a string.
- Change the key loaders to take a UI_METHOD instead of a callback
function pointer. NOTE: this breaks binary compatibility with
earlier versions of OpenSSL [engine].
- Addapt the nCipher code for these new conditions and add a card
insertion callback.
prompting, application-defined prompts, the possibility to use
defaults (for example default passwords from somewhere else) and
interrupts/cancelations.
In the new crypto/ui/, this was changed into tty (which is usually
/dev/tty), i.e. the FILE * used for reading passwords from the user.
However stdio buffering for read/write streams is not without pitfalls
(passwords would be echoed on some systems).
To avoid problems, split tty into tty_in and tty_out (which are
opened separately).
(for new functions...). One might still want to be able to pass down
a user-data pointer to be used by the UI. However, ex_data doesn't
quite cut it, since that means the appropriate index to it might need
to be shared between parts that aren't really related in that sense,
and would require the currently hidden (static) index holders to be
uncovered. Not a good thing. Therefore, add the possibility to add a
user-data pointer to a UI.
details (performance numbers and accompanying discussions:-). Note that
the code is not engaged in ./Configure yet. I'll add it later this week
along with updates for .spec file.
Submitted by:
Reviewed by:
PR:
passwords that were given to the key loading functions were completely
ignored, at least in the ncipher code, and then we made the assumption
that the callback wanted a prompt as user argument.
All that is now changed, and the application author is forced to give
a callback function of type pem_callback_cb and possibly an argument
for it, just as for all other functions that want to generate password
prompting.
NOTE: this change creates binary and source incompatibilities with
previous versions of OpenSSL [engine]. It's worth it this time, to
get it right (or at least better and with a chance that it'll work).
Only use trust settings if either trust or reject settings
are present, otherwise use compatibility mode. This stops
root CAs being rejected if they have alias of keyid set.
For some unknown reason fopen("con", "w") is the
only way to make this work. Using "r+" and "w+"
causes the fopen call to fail and the fallback
(using stdin) doesn't work because writing to stdin
fails.
like des_read_password and friends (backward compatibility functions
using this new API are provided). The purpose is to remove prompting
functions from the DES code section as well as provide for prompting
through dialog boxes in a window system and the like.
For those, unless the environment variables RANDFILE or HOME are
defined (the default case!), RAND_file_name() will return NULL.
This change adds a default HOME for those platforms.
To add a default HOME for any platform, just define DEFAULT_HOME in
the proper place, wrapped in appropriate #ifdef..#endif, in e_os.h.
few statements equivalent to "ENGINE_add(ENGINE_openssl())" etc. The inner
call to ENGINE_openssl() (as with other functions like it) orphans a
structural reference count. Second, the ENGINE_cleanup() function also
needs to clean up the functional reference counts held internally as the
list of "defaults" (ie. as used when RSA_new() requires an appropriate
ENGINE reference). So ENGINE_clear_defaults() was created and is called
from within ENGINE_cleanup(). Third, some of the existing code was
logically broken in its treatment of reference counts and locking (my
fault), so the necessary bits have been restructured and tidied up.
To test this stuff, compiling with ENGINE_REF_COUNT_DEBUG will cause every
reference count change (both structural and functional) to log a message to
'stderr'. Using with "openssl engine" for example shows this in action
quite well as the 'engine' sub-command cleans up after itself properly.
Also replaced some spaces with tabs.
* "ex_data" - a CRYPTO_EX_DATA structure in the ENGINE structure itself
that allows an ENGINE to store its own information there rather than in
global variables. It follows the declarations and implementations used
in RSA code, for better or worse. However there's a problem when storing
state with ENGINEs because, unlike related structure types in OpenSSL,
there is no ENGINE-vs-ENGINE_METHOD separation. Because of what ENGINE
is, it has method pointers as its structure elements ... which leads
to;
* ENGINE_FLAGS_BY_ID_COPY - if an ENGINE should not be used just as a
reference to an "implementation" (eg. to get to a hardware device), but
should also be able to maintain state, then this flag can be set by the
ENGINE implementation. The result is that any call to ENGINE_by_id()
will not result in the existing ENGINE being returned (with its
structural reference count incremented) but instead a new copy of the
ENGINE will be returned that can maintain its own state independantly of
any other copies returned in the past or future. Eg. key-generation
might involve a series of ENGINE-specific control commands to set
algorithms, sizes, module-keys, ids, ACLs, etc. A final command could
generate the key. An ENGINE doing this would *have* to declare
ENGINE_FLAGS_BY_ID_COPY so that the state of that process can be
maintained "per-handle" and unaffected by other code having a reference
to the same ENGINE structure.
