crypto/rijndael. Additionally, I applied the AES integration patch
from Stephen Sprunk <stephen@sprunk.org> and fiddled it to work
properly with the normal EVP constructs (and incidently work the same
way as all other symmetric cipher implementations).
This results in an API that looks a lot like the rest of the OpenSSL
cipher suite.
characters with the highest bit set as HIGHBIT. We need to expand
this to support the UTF-8 character set properly. However, this
solves the problem that the character 0x80 (which is common in UTF-8)
gets masked to 0x00.
Patch submitted by "Huang Yuzhen" <huangyuzhen@bj.tom.com>
<sram@broadcom.com> with the following comment:
[...] We have implemented failover (ie, if for some reason that the
hardware fails, the implementation detects this failure and performs
this operation as if no hardware is present, ie, in software) for
sometime now and have tested it here with our hardware. [...]
This change was cc:ed to exports@crypto.com
1. some platforms do not have inttypes.h, and chasing them down
becomes ridiculous. Therefore, uint64_t can't be used for 64-bit
values.
2. some (other) platforms do not support "long long".
Solution: make AEP_U64 a struct with two longs unless long already is
64 bit long.
Also, restore all other types back to use unsigned char, unsigned int
and unsigned long. Make sure that AEP_U32 actually becomes 32 bits,
even on platforms where long is 64 bits (actually, we're just guessing
that int will stay at 32 bits on those...).
RFCs concerning X.500 directories use UID as a shorter name for the
attribute type userId, which is defined by CCITT and available through
RFCs 1274 and 2247.
Unfortunately, if some applications have used the name "UID" for the
uniqueIdentifier attribute type, they will produce incorrect results.
However, I found it better to follow the standards that are out there
rather than having our own incompatible one.
