- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

When porting XTS-related code from OpenBSD I forgot to update copyright (only
OpenBSD was credited in one of two commits). Fix it.

Reported by: Theo de Raadt <deraadt@cvs.openbsd.org>
Reviewed by: Damien Miller <djm@mindrot.org>

Add support for AES-XTS.

Obtained from: OpenBSD
MFC after: 1 week

Remove redundant space.

MFC after: 1 week

Retire the MALLOC and FREE macros. They are an abomination unto style(9).

MFC after: 3 months

Integrate the Camellia Block Cipher. For more information see RFC 4132
and its bibliography.

Submitted by: Tomoyuki Okazaki <okazaki at kick dot gr dot jp>
MFC after: 1 month

Use newly added defines instead of magic values.

- Fix a very old bug in HMAC/SHA{384,512}. When HMAC is using SHA384
or SHA512, the blocksize is 128 bytes, not 64 bytes as anywhere else.
The bug also exists in NetBSD, OpenBSD and various other independed
implementations I look at.
- We cannot decide which hash function to use for HMAC based on the key
length, because any HMAC function can use any key length.
To fix it split CRYPTO_SHA2_HMAC into three algorithm:
CRYPTO_SHA2_256_HMAC, CRYPTO_SHA2_384_HMAC and CRYPTO_SHA2_512_HMAC.
Those names are consistent with OpenBSD's naming.
- Remove authsize field from auth_hash structure.
- Allow consumer to define size of hash he wants to receive.
This allows to use HMAC not only for IPsec, where 96 bits MAC is requested.
The size of requested MAC is defined at newsession time in the cri_mlen
field - when 0, entire MAC will be returned.
- Add swcr_authprepare() function which prepares authentication key.
- Allow to provide key for every authentication operation, not only at
newsession time by honoring CRD_F_KEY_EXPLICIT flag.
- Make giving key at newsession time optional - don't try to operate on it
if its NULL.
- Extend COPYBACK()/COPYDATA() macros to handle CRYPTO_BUF_CONTIG buffer
type as well.
- Accept CRYPTO_BUF_IOV buffer type in swcr_authcompute() as we have
cuio_apply() now.
- 16 bits for key length (SW_klen) is more than enough.

Reviewed by: sam

Check key size for rijndael, as invalid key size can lead to kernel panic.
It checked other algorithms against this bug and it seems they aren't
affected.

Reported by: Mike Tancsa <mike@sentex.net>
PR: i386/84860
Reviewed by: phk, cperciva(x2)

just use crypto/rijndael, and nuke opencrypto/rindael.[ch].
the two became almost identical since latest KAME merge.

Discussed with: sam

- use 1/2 space for rijndael context in ipsec
- rijndael_set_key() always sets up full context
- rijndaelKeySetupDec() gets back original protoype

Reviewed by: sam
Obtained from: OpenBSD

/* -> /*- for license, minor formatting changes

Use __FBSDID().

In-kernel crypto framework derived from openbsd. This facility provides
a consistent interface to h/w and s/w crypto algorithms for use by the
kernel and (for h/w at least) by user-mode apps. Access for user-level
code is through a /dev/crypto device that'll eventually be used by openssl
to (potentially) accelerate many applications. Coming soon is an IPsec
that makes use of this service to accelerate ESP, AH, and IPCOMP protocols.

Included here is the "core" crypto support, /dev/crypto driver, various
crypto algorithms that are not already present in the KAME crypto area,
and support routines used by crypto device drivers.

Obtained from: openbsd