Catch attempted use of non FIPS algorithms with HMAC.
Give an assertion error for applications that ignore FIPS digest errors.
Make -non-fips-allow work with dgst and HMAC.
Non FIPS algorithms are not normally allowed in FIPS mode.
Any attempt to use them via high level functions will return an error.
The low level non-FIPS algorithm functions cannot return errors so they
produce assertion failures. HMAC also has to give an assertion error because
it (erroneously) can't return an error either.
There are exceptions (such as MD5 in TLS and non cryptographic use of
algorithms) and applications can override the blocking and use non FIPS
algorithms anyway.
For low level functions the override is perfomed by prefixing the algorithm
initalization function with "private_" for example private_MD5_Init().
For high level functions an override is performed by setting a flag in
the context.
locality on 64-bit platforms (and fixes IA64 assembler-empowered build:-).
The choice is guarded by newly introduced AES_LONG macro, which needs
to be defined only on 16-bit platforms which we don't support (not that
I know of). Meaning that one could as well skip long option altogether.
- Enforce that there should be no policy settings when the language
is one of id-ppl-independent or id-ppl-inheritAll.
- Add functionality to ssltest.c so that it can process proxy rights
and check that they are set correctly. Rights consist of ASCII
letters, and the condition is a boolean expression that includes
letters, parenthesis, &, | and ^.
- Change the proxy certificate configurations so they get proxy
rights that are understood by ssltest.c.
- Add a script that tests proxy certificates with SSL operations.
Other changes:
- Change the copyright end year in mkerr.pl.
- make update.
memory BIO (for example from SMIME_read_PKCS7 and detached data) avoid lots
of slow memory copies from the memory BIO by saving the content in a
temporary read only memory BIO.
memory BIO (for example from SMIME_read_PKCS7 and detached data) avoid lots
of slow memory copies from the memory BIO by saving the content in a
temporary read only memory BIO.
certain mix of calls to RC4 routine not covered by rc4test.c.
It's fixed now. In addition this patch inadvertently fixes minor
performance problem: in 0.9.7 context P4 was performing 12% slower
than the original implementation...
check_ca(), to resolve constness issue. check_ca() is called from the
purpose checkers instead of X509_check_ca(), since the stuff done by
the latter (except for calling check_ca()) is also done by
X509_check_purpose().
check_ca(), to resolve constness issue. check_ca() is called from the
purpose checkers instead of X509_check_ca(), since the stuff done by
the latter (except for calling check_ca()) is also done by
X509_check_purpose().
CA setting in each certificate on the chain is correct. As a side-
effect always do the following basic checks on extensions, not just
when there's an associated purpose to the check:
- if there is an unhandled critical extension (unless the user has
chosen to ignore this fault)
- if the path length has been exceeded (if one is set at all)
- that certain extensions fit the associated purpose (if one has been
given)
CA setting in each certificate on the chain is correct. As a side-
effect always do the following basic checks on extensions, not just
when there's an associated purpose to the check:
- if there is an unhandled critical extension (unless the user has
chosen to ignore this fault)
- if the path length has been exceeded (if one is set at all)
- that certain extensions fit the associated purpose (if one has been
given)
apparently impossible to compose blended code with would perform
satisfactory on all x86 and x86_64 cores, an extra RC4_CHAR
code-path is introduced and P4 core is detected at run-time. This
way we keep original performance on non-P4 implementations and
turbo-charge P4 performance by factor of 2.8x (on 32-bit core).
guys had to change the name to differentiate with older versions when
a backward incompatibility came up. Of course, we need to adapt.
This change simply tries to load the library through the newer name
(ZLIB1) first, and if that fails, it tries the good old ZLIB.
guys had to change the name to differentiate with older versions when
a backward incompatibility came up. Of course, we need to adapt.
This change simply tries to load the library through the newer name
(ZLIB1) first, and if that fails, it tries the good old ZLIB.
"remaining relocations" in assembler modules. The latter seems to
be new behaviour, elder as/ld managed to resolve this relocations
as internal. It's possible to address this problem differently,
but I settle for -Bsymbolic...
PR: 546
for LPdir_unix.c in LPlib. For the other files, only the last log
entry applies.
----------------------------
revision 1.11
date: 2004/09/23 22:07:22; author: _cvs_levitte; state: Exp; lines: +20 -6
Define my own macro LP_ENTRY_SIZE to express the size of my own
buffering of directory entries, and make it depend on whichever comes
first of PATH_MAX and NAME_MAX. As a fallback, make sure it's set to
255 if neither PATH_MAX or NAME_MAX were defined. Also, if the size
given from PATH_MAX or NAME_MAX is less than 255, force LP_ENTRY_SIZE
to be 255.
It makes no harm whatsoever if LP_ENTRY_SIZE is larger than the
maximum local path name limit. It does make a lot of harm if
LP_ENTRY_SIZE is smaller. 255 seemed like a fairly acceptable default
when nothing else is available.
----------------------------
revision 1.10
date: 2004/08/26 13:36:05; author: _cvs_levitte; state: Exp; lines: +13 -13
License correction. I am not REGENTS, just a COPYRIGHT HOLDER.
----------------------------
the form MBSTRING_FLAG|nbyte where "nbyte" is the number of
bytes per character.
Unfortunately this isn't so and we can't change the #defines because
this would break binary compatibility, so for 0.9.7X only translate
between the two.
- Move the inclusion of malloc.h until after all other includes, so we
can do proper tests of system macros.
- Make sure the correct header file is included to get the builtin
"alloca" under VMS, and define a macro to map the symbol 'alloca' to
it.
This tidies up verify parameters and adds support for integrated policy
checking.
Add support for policy related command line options. Currently only in smime
application.
WARNING: experimental code subject to change.
x86*_nw.pl will be deleted. In addition this update implements initseg
on several additional [in addition to ELF] platforms. Functions registered
with initseg are supposed to be called prior main().
to bother creating a BIO around it. So here's a few more functions to
make it possible to make the dump using a printing callback, and to
print to a FILE* (based on the callback variant), done in the same
style as the functions in crypto/err/err_prn.c.
performing AES encryption in hardware, as well as one accessing
hardware RNG. As you surely imagine this engine access this
extended instruction set. Well, only AES for the moment, support
for RNG is to be added later on...
PR: 889
Submitted by: Michal Ludvig <michal@logix.cz>
Obtained from: http://www.logix.cz/michal/devel/padlock/
COFF and a.out targets [similar to ELF targets]. You might notice some
rudementary support for shared mingw builds under cygwin. It works (it
produces cryptoeay32.dll and ssleay32.dll with everything exported by
name), but it's primarily for testing/debugging purposes, at least for
now...
if we explicitly intruct the linker to set entry point, then we become
obliged to initialize run-time library. Instead we can pick name run-time
will call and such name is DllMain. Note that this applies to both
"native" Win32 environment and Cygwin:-)
around them.
NOTE: because two new locks are added, this adds potential binary
incompatibility with earlier versions in the 0.9.7 series. However,
those locks will only ever be touched when FIPS_mode_set() is called
and after, thanks to a variable that's only changed from 0 to 1 once
(when FIPS_mode_set() is called). So basically, as long as FIPS mode
hasn't been engaged explicitely by the calling application, the new
locks are treated as if they didn't exist at all, thus not becoming a
problem. Applications that are built or rebuilt to use FIPS
functionality will need to be recompiled in any case, thus not being a
problem either.
