History log of /netbsd-src/sys/opencrypto/files.opencrypto (Results 1 – 25 of 30)
Revision Date Author Comments
# 8835ffd0 29-Jun-2020 riastradh <riastradh@NetBSD.org>

opencrypto: Switch from legacy rijndael API to new aes API.

While here, apply various rijndael->aes renames, reduce the size
of aesxcbc_ctx by 480 bytes, and convert some malloc->kmem.

Leave in the

opencrypto: Switch from legacy rijndael API to new aes API.

While here, apply various rijndael->aes renames, reduce the size
of aesxcbc_ctx by 480 bytes, and convert some malloc->kmem.

Leave in the symbol enc_xform_rijndael128 for now, though, so this
doesn't break any kernel ABI.

show more ...


# b203ba40 22-Apr-2020 rin <rin@NetBSD.org>

Make crypto/rijindael optional again as cprng_strong does no longer
depend on it. Dependency is explicitly declared in files.foo if a
component requires it.


# 9d7a921f 27-Jan-2020 pgoyette <pgoyette@NetBSD.org>

Split the module glue out from the rest of opencrypto/ocryptodev to
make rump happy.

Rump doesn't have compat modules (the compat code is included in the
relevant librump*.so), so there's no module

Split the module glue out from the rest of opencrypto/ocryptodev to
make rump happy.

Rump doesn't have compat modules (the compat code is included in the
relevant librump*.so), so there's no module compat_50 listed in
link_set_modules, and thus ocryptodev's MODULE(...) can't "require"
it.

This fixes the problem of "built-in module compat_50 not found" when
starting up rump_allserver (or rump_server with -l rumpdev_opencrypto).

XXX This does not resolve the long-standing "crypto: unable to
XXX register devsw, error 17" message noted at line 78 of
XXX sys/rump/dev/lib/libopencrypto/opencrypto_component.c

show more ...


# d91f98a8 27-Jan-2019 pgoyette <pgoyette@NetBSD.org>

Merge the [pgoyette-compat] branch


# c7023dc1 24-May-2017 knakahara <knakahara@NetBSD.org>

make the default values of q_maxlen build parameters.


# 3afd44cf 19-Nov-2011 tls <tls@NetBSD.org>

First step of random number subsystem rework described in
<20111022023242.BA26F14A158@mail.netbsd.org>. This change includes
the following:

An initial cleanup and minor reorganization of the entro

First step of random number subsystem rework described in
<20111022023242.BA26F14A158@mail.netbsd.org>. This change includes
the following:

An initial cleanup and minor reorganization of the entropy pool
code in sys/dev/rnd.c and sys/dev/rndpool.c. Several bugs are
fixed. Some effort is made to accumulate entropy more quickly at
boot time.

A generic interface, "rndsink", is added, for stream generators to
request that they be re-keyed with good quality entropy from the pool
as soon as it is available.

The arc4random()/arc4randbytes() implementation in libkern is
adjusted to use the rndsink interface for rekeying, which helps
address the problem of low-quality keys at boot time.

An implementation of the FIPS 140-2 statistical tests for random
number generator quality is provided (libkern/rngtest.c). This
is based on Greg Rose's implementation from Qualcomm.

A new random stream generator, nist_ctr_drbg, is provided. It is
based on an implementation of the NIST SP800-90 CTR_DRBG by
Henric Jungheim. This generator users AES in a modified counter
mode to generate a backtracking-resistant random stream.

An abstraction layer, "cprng", is provided for in-kernel consumers
of randomness. The arc4random/arc4randbytes API is deprecated for
in-kernel use. It is replaced by "cprng_strong". The current
cprng_fast implementation wraps the existing arc4random
implementation. The current cprng_strong implementation wraps the
new CTR_DRBG implementation. Both interfaces are rekeyed from
the entropy pool automatically at intervals justifiable from best
current cryptographic practice.

In some quick tests, cprng_fast() is about the same speed as
the old arc4randbytes(), and cprng_strong() is about 20% faster
than rnd_extract_data(). Performance is expected to improve.

The AES code in src/crypto/rijndael is no longer an optional
kernel component, as it is required by cprng_strong, which is
not an optional kernel component.

The entropy pool output is subjected to the rngtest tests at
startup time; if it fails, the system will reboot. There is
approximately a 3/10000 chance of a false positive from these
tests. Entropy pool _input_ from hardware random numbers is
subjected to the rngtest tests at attach time, as well as the
FIPS continuous-output test, to detect bad or stuck hardware
RNGs; if any are detected, they are detached, but the system
continues to run.

A problem with rndctl(8) is fixed -- datastructures with
pointers in arrays are no longer passed to userspace (this
was not a security problem, but rather a major issue for
compat32). A new kernel will require a new rndctl.

The sysctl kern.arandom() and kern.urandom() nodes are hooked
up to the new generators, but the /dev/*random pseudodevices
are not, yet.

Manual pages for the new kernel interfaces are forthcoming.

show more ...


# 0a8dabda 26-May-2011 drochner <drochner@NetBSD.org>

pull in AES-GCM/GMAC support from OpenBSD
This is still somewhat experimental. Tested between 2 similar boxes
so far. There is much potential for performance improvement. For now,
I've changed the gm

pull in AES-GCM/GMAC support from OpenBSD
This is still somewhat experimental. Tested between 2 similar boxes
so far. There is much potential for performance improvement. For now,
I've changed the gmac code to accept any data alignment, as the "char *"
pointer suggests. As the code is practically used, 32-bit alignment
can be assumed, at the cost of data copies. I don't know whether
bytewise access or copies are worse performance-wise. For efficient
implementations using SSE2 instructions on x86, even stricter
alignment requirements might arise.

show more ...


# ebc232a5 24-May-2011 drochner <drochner@NetBSD.org>

copy AES-XCBC-MAC support from KAME IPSEC to FAST_IPSEC
For this to fit, an API change in cryptosoft was adopted from OpenBSD
(addition of a "Setkey" method to hashes) which was done for GCM/GMAC
sup

copy AES-XCBC-MAC support from KAME IPSEC to FAST_IPSEC
For this to fit, an API change in cryptosoft was adopted from OpenBSD
(addition of a "Setkey" method to hashes) which was done for GCM/GMAC
support there, so it might be useful in the future anyway.
tested against KAME IPSEC
AFAICT, FAST_IPSEC now supports as much as KAME.

show more ...


# 3d2cef17 05-May-2011 drochner <drochner@NetBSD.org>

support camellia-cbc by swcrypt


# c3a6a9f4 19-Feb-2011 drochner <drochner@NetBSD.org>

make the compatibility code conditional on COMPAT_50


# 36ea3668 25-Mar-2009 darran <darran@NetBSD.org>

Fixes PR kern/41069 and PR kern/41070.

Extends the Opencrypto API to allow the destination buffer size to be
specified when its not the same size as the input buffer (i.e. for
operations like compre

Fixes PR kern/41069 and PR kern/41070.

Extends the Opencrypto API to allow the destination buffer size to be
specified when its not the same size as the input buffer (i.e. for
operations like compress and decompress).
The crypto_op and crypt_n_op structures gain a u_int dst_len field.
The session_op structure gains a comp_alg field to specify a compression
algorithm.
Moved four ioctls to new ids; CIOCGSESSION, CIOCNGSESSION, CIOCCRYPT,
and CIOCNCRYPTM.
Added four backward compatible ioctls; OCIOCGSESSION, OCIOCNGSESSION,
OCIOCCRYPT, and OCIOCNCRYPTM.

Backward compatibility is maintained in ocryptodev.h and ocryptodev.c which
implement the original ioctls and set dst_len and comp_alg to 0.

Adds user-space access to compression features.

Adds software gzip support (CRYPTO_GZIP_COMP).

Adds the fast version of crc32 from zlib to libkern. This should be generally
useful and provide a place to start normalizing the various crc32 routines
in the kernel. The crc32 routine is used in this patch to support GZIP.

With input and support from tls@NetBSD.org.

show more ...


# e5bd2a12 04-Feb-2008 tls <tls@NetBSD.org>

Rework opencrypto to use a spin mutex (crypto_mtx) instead of "splcrypto"
(actually splnet) and condvars instead of tsleep/wakeup. Fix a few
miscellaneous problems and add some debugging printfs whi

Rework opencrypto to use a spin mutex (crypto_mtx) instead of "splcrypto"
(actually splnet) and condvars instead of tsleep/wakeup. Fix a few
miscellaneous problems and add some debugging printfs while there.

Restore set of CRYPTO_F_DONE in crypto_done() which was lost at some
point after this code came from FreeBSD -- it made it impossible to wait
properly for a condition.

Add flags analogous to the "crp" flags to the key operation's krp struct.
Add a new flag, CRYPTO_F_ONRETQ which tells us a request finished before
the kthread had a chance to dequeue it and call its callback -- this was
letting requests stick on the queues before even though done and copied
out.

Callers of crypto_newsession() or crypto_freesession() must now take the
mutex. Change netipsec to do so. Dispatch takes the mutex itself as
needed.

This was tested fairly extensively with the cryptosoft backend and lightly
with a new hardware driver. It has not been tested with FAST_IPSEC; I am
unable to ascertain whether FAST_IPSEC currently works at all in our tree.

pjd@FreeBSD.ORG, ad@NetBSD.ORG, and darran@snark.us pointed me in the
right direction several times in the course of this. Remaining bugs
are mine alone.

show more ...


# 31a62606 27-Oct-2006 christos <christos@NetBSD.org>

Merge kernel and userland rmd160 and sha2 implementation.
XXX: We still install rmd160.h and sha2.h in /usr/include/crypto, unlike
the other hash functions which get installed in /usr/include for com

Merge kernel and userland rmd160 and sha2 implementation.
XXX: We still install rmd160.h and sha2.h in /usr/include/crypto, unlike
the other hash functions which get installed in /usr/include for compatibility.

show more ...


# cfc81086 25-Nov-2005 thorpej <thorpej@NetBSD.org>

swcr -> swcrypto


# 7bc6d90c 25-Nov-2005 thorpej <thorpej@NetBSD.org>

- De-couple the software crypto implementation from the rest of the
framework. There is no need to waste the space if you are only using
algoritms provided by hardware accelerators. To get the

- De-couple the software crypto implementation from the rest of the
framework. There is no need to waste the space if you are only using
algoritms provided by hardware accelerators. To get the software
implementations, add "pseudo-device swcr" to your kernel config.
- Lazily initialize the opencrypto framework when crypto drivers
(either hardware or swcr) register themselves with the framework.

show more ...


# bcfcddba 26-Feb-2005 perry <perry@NetBSD.org>

nuke trailing whitespace


# 01c51dab 31-Dec-2003 jonathan <jonathan@NetBSD.org>

Split opencrypto configuration into an attribute, usable by inkernel
clients, and a pseudo-device for userspace access.

The attribute is named `opencrypto'. The pseudo-device is renamed to
"crypto",

Split opencrypto configuration into an attribute, usable by inkernel
clients, and a pseudo-device for userspace access.

The attribute is named `opencrypto'. The pseudo-device is renamed to
"crypto", which has a dependency on "opencrypto". The sys/conf/majors
entry and pseudo-device attach entrypoint are updated to match the
new pseudo-device name.

Fast IPsec (sys/netipsec/files.ipsec) now lists a dependency on the
"opencrypto" attribute. Drivers for crypto accelerators (ubsec,
hifn775x) also pull in opencrypto, as providers of opencrypto transforms.

show more ...


# 1f93975c 16-Nov-2003 tls <tls@NetBSD.org>

Move the Skipjack algorithm from sys/opencrypto to sys/crypto/skipjack.
There are now no cryptographic algorithms in sys/opencrypto, which,
according to the comment formerly in files.opencrypto, was

Move the Skipjack algorithm from sys/opencrypto to sys/crypto/skipjack.
There are now no cryptographic algorithms in sys/opencrypto, which,
according to the comment formerly in files.opencrypto, was the original
intent.

show more ...


# 24b18cc2 27-Aug-2003 thorpej <thorpej@NetBSD.org>

Use the Blowfish in crypto/blowfish, which has hooks for using tuned
assembly for the transform.


# 6de9ce04 26-Aug-2003 thorpej <thorpej@NetBSD.org>

Move the opencrypto CAST-128 implementation to crypto/cast128, removing
the old one. Rename the functions/structures from cast_* to cast128_*.
Adapt the KAME IPsec to use the new CAST-128 code, whic

Move the opencrypto CAST-128 implementation to crypto/cast128, removing
the old one. Rename the functions/structures from cast_* to cast128_*.
Adapt the KAME IPsec to use the new CAST-128 code, which has a simpler
API and smaller footprint.

show more ...


# aa6632ba 26-Aug-2003 thorpej <thorpej@NetBSD.org>

G/C opencrypto's local copy of rijndael. Adapt the extant rijndael
code for opencrypto's use by adding the simplified API that opencrypto
expects.


# a7b80200 24-Aug-2003 thorpej <thorpej@NetBSD.org>

crypto_mbuf.c is unused; remove it.


# 6c52220e 24-Aug-2003 thorpej <thorpej@NetBSD.org>

G/C some unused config definitions.


# 633cb7d7 24-Aug-2003 thorpej <thorpej@NetBSD.org>

Make opencrypto depend on the "ripemd160" and "sha2" attributes, rather
than polluting the crypto algorithm config info with opencrypto knowledge.


# 35479644 24-Aug-2003 thorpej <thorpej@NetBSD.org>

Move the opencrypto defpseudo into files.opencrypto.


12