From kernel objects at msdn:
Kernel object handles are process specific. That is, a process must either create the object or open an existing object to obtain a kernel object handle. The per-process limit on kernel handles is 2^24.
Windows Internals by Russinovich and Solomon as well says that the high bits are zero.
The 3-key and 2-key Triple DES PBE functions have been replaced with a
single pkcs12_pbe() function that handles both situations (and more).
In addition this allows for some PASSWORD_MISMATCH checking
POLARSSL_ERR_X509_PASSWORD_MISMATCH is returned instead of
POLARSSL_ERR_PEM_PASSWORD_MISMATCH and
POLARSSL_ERR_X509_PASSWORD_REQUIRED instead of
POLARSSL_ERR_PEM_PASSWORD_REQUIRED
Rationale: For PKCS#8 encrypted keys the same are returned
The error code POLARSSL_ERR_X509_PASSWORD_MISMATCH is now properly
returned in case of an encryption failure in the padding. The
POLARSSL_ERR_X509_PASSWORD_REQUIRED error code is only returned for PEM
formatted private keys as for DER formatted ones it is impossible to
distinguish if a DER blob is PKCS#8 encrypted or not.
All symmetric cipher algorithms and hash algorithms now include support
for a POLARSSL_XXX_ALT flag that prevents the definition of the
algorithm context structure and all 'core' functions.
PKCS#8 encrypted key file support has been added to x509parse_key() with
support for some PCKS#12 PBE functions (pbeWithSHAAnd128BitRC4,
pbeWithSHAAnd3-KeyTripleDES-CBC and pbeWithSHAAnd2-KeyTripleDES-CBC)
Split up x509parse_key() into a (PEM) handler function and specific
DER parser functions for the PKCS#1 (x509parse_key_pkcs1_der()) and
unencrypted PKCS#8 (x509parse_key_pkcs8_unencrypted_der()) private
key formats.
Because of new pem_read_buffer() handling of when it writes use_len,
x509parse_crt() is able to better handle situations where a PEM blob
results in an error but the other blobs can still be parsed.
After header and footer are read, pem_read_buffer() is able to determine
the length of input data used. This allows calling functions to skip
this PEM bit if an error occurs during its parsing.
Rationale: The HAVEGE random generator has too many caveats to be a
standard generator that people rely on. The HAVEGE random generator is not
suitable for virtualized environments. In addition the HAVEGE random
generator is dependent on timing and specific processor traits that
cannot be guaranteed by default on compile time.
Our advice: only use HAVEGE as an additional random source for your
entropy pool, never as your primary source.
