NSP(4) BSD Kernel Interfaces Manual NSP(4)
nsp -- NBMK/CyberGuard/NetOctave NSP2000 crypto accelerator
nsp* at pci? dev ? function ?
The nsp driver supports cards using the NSP2000 cryptographic processor, originally manufac-
tured and sold by NetOctave, then CyberGuard, and presently (late 2008) by NBMK Encryption
The NSP2000 is a cryptographic ``packet processor'' or ``macro processor'' featuring exten-
sive support for protocol handshake acceleration and protocol record operations (e.g. sin-
gle-pass pad-encrypt-and-hash for SSL or ESP messages). It also provides various crypto-
graphic and mathematical primitives such as random number generation, encryption/decryption
(DES, 3DES, and RC4), hash computation (MD5, SHA1, and HMAC), and an extensive set of opera-
tions for arbitrary precision arithmetic. It contains a tamper-resistant write-only memory
region for storage of cryptographic keys.
The nsp driver registers support for the following operations with opencrypto(9):
CRYPTO_DES_CBC DES in CBC mode.
CRYPTO_3DES_CBC Triple-DES in CBC mode.
CRYPTO_MD5 The MD5 hash algorithm.
CRYPTO_SHA1 The SHA-1 hash algorithm.
CRYPTO_SHA1_HMAC The HMAC message authentication code using SHA-1 as the hash func-
CRYPTO_MD5_HMAC The HMAC message authentication code using MD5 as the hash func-
CRK_MOD Compute x modulo y.
CRK_MOD_ADD Modular addition.
CRK_MOD_ADDINV Modular additive inversion.
CRK_MOD_SUB Modular subtraction.
CRK_MOD_MULT Modular multiplication.
CRK_MOD_MULTINV Modular multiplicative inversion.
CRK_MOD_EXP Modular exponentiation.
CRK_DSA_SIGN DSA signature creation.
CRK_DSA_VERIFY DSA signature verification.
CRK_DH_COMPUTE_KEY Diffie-Hellman key computation.
The nsp driver can perform several hundred 1024-bit RSA operations per second, and can
encrypt and hash about 200Mbit/sec of data with symmetric operations. Each figure is
approximately 1/3 the rated throughput for the device.
Several restrictions limit the performance of this driver:
1. The CRK_MOD_EXP_CRT operation (modular exponentiation with operands in Chinese Remain-
der Theorem form) is unfortunately not supported because the opencrypto(9) interface
specifies this operation in a way which may only be compatible with the ubsec(4) accel-
2. The handshake operations and record transforms are not supported as they are a poor fit
for the current opencrypto(9) API. Support for either would require a method of pass-
ing record-transform contexts between layers of the framework, likely in both direc-
tions across the user-kernel boundary. Without record operations, the host CPU will
almost always perform RC4 faster than the NSP2000, so RC4 support is disabled in the
3. The on-board key memory is not supported. It would be relatively easy to add support
for this feature to opencrypto(9), but the interface for supporting this functionality
in OpenSSL in OpenSSL is complex and poorly documented, which makes kernel support use-
4. The OpenSSL ``engine'' for crypto(4) does not yet support the HMAC forms of the hash
operations, which roughly halves performance for many workloads.
On a more positive note, the NSP2000 and nsp driver offer excellent performance for small
modular arithmetic operations, achieving 75,000 or more such operations per second.
crypto(4), fast_ipsec(4), intro(4), rnd(4), opencrypto(9)
The nsp device driver is descended from the NetOctave SDK for FreeBSD 4.11, where it was
called ``noct''. It is unrelated to the driver of that name which appeared in OpenBSD 3.2,
which does not support the public-key (or other bignum) functions of the device. The nsp
driver was ported to NetBSD 5.0 by Coyote Point Systems, Inc and generously made available
under a BSD-style license by NBMK Encryption Technologies, Inc, the corporate successor of
The nsp device driver does not currently support the device node interface provided by the
original NetOctave ``noct'' driver (which offers handshake acceleration, record operations,
memory-mapped handling of packet payloads, and several other useful features) but most of
the code to do so is still present, albeit in untested form.
Support for limitations of the NSP2000 PCI interface (broken burst-mode operation, lack of
scatter-gather support) is present but tested only on a fairly small range of host systems.
It appears that most if not all NSP2000 cards ever manufactured were designed to carry
either one or two accelerator chips, which suggests that cards exist with both chips popu-
lated. The nsp driver has never been tested with more than one instance present at a time.
BSD November 2, 2008 BSD