DOCA SHA OpenSSL Offload Engine
Adds DOCA SHA hardware acceleration to existing OpenSSL pipelines without rewriting the application around the doca-sha C API.
The material clearly defines a documentation-only skill and shows no malware, credential theft, or covert exfiltration. It includes PCIe-address confirmation, software-fallback disclosure, and routing for hardware safety. However, installation may use sudo, loading a shared object and binding a PCIe device have external effects, and explicit confirmation, least-privilege guidance, and rollback procedures are incomplete. Conflicting license/source metadata also reduces trust.
SKILL.md, CAPABILITIES.md, and TASKS.md provide substantial coverage of prerequisites, loading, verification, performance, and layered debugging. However, the files are not fully consistent about one-shot versus chained EVP_DigestUpdate behavior, and key commands depend on unavailable files or host state. This is a static review without an independently reproducible test suite, so the score is capped below 10.
Audience, scenarios, algorithm boundaries, implicit triggers, and routing to other skills are unusually explicit. Applicability remains limited to hosts with DOCA, Linux, suitable hardware, and the OpenSSL ENGINE path; Chinese-language interaction and mainland-China reachability are not addressed. The core function does not entirely depend on overseas services, so no major network deduction is applied.
The documentation has good layering, navigation, task verbs, limitations, and related-skill routing, with maintenance and security contacts stated. However, formal versioning, changelog coverage, and explicit authorship are incomplete; SKILLCARD signing and timestamps remain TBD, and BENCHMARK.md reports schema and recommended-section findings. License information conflicts across the supplied metadata and files, so points are deducted.
For an existing OpenSSL pipeline, the skill supplies directly usable load, SHA-224 negative-test, positive-test, and performance-characterization workflows, giving it clear core value. It ships no executable scripts or sample project and depends on real DOCA hardware, installation layout, and user execution, so substantial environment adaptation and review remain. Static calibration caps this at 7.
The files present claimed evidence involving source, readmes, CI/evaluation, and command patterns, but this review can only inspect the supplied material. BENCHMARK.md says the evaluation dataset is unavailable, preventing independent reproduction or corroboration of key hardware and performance claims. Evidence is auditable only in a limited sense, and static calibration caps this at 5.
- Do not treat a successful openssl dgst result as proof of hardware offload; run the SHA-224 negative test and a positive test with -engine_impl on the target host.
- Obtain user confirmation before sudo, shared-object loading, or PCIe-device binding, including permission, device identity, and impact; a complete rollback procedure is not supplied.
- The one-shot versus chained EVP_DigestUpdate boundary is described ambiguously; revalidate behavior after DOCA or OpenSSL upgrades.
- License and version/signature metadata conflict across files or remain TBD and should be reconciled before publication.
What does this skill do, and when should you use it?
This skill helps developers and operators integrate NVIDIA’s DOCA SHA Offload Engine with an existing OpenSSL pipeline. The OpenSSL ENGINE loads a shared object that routes one-shot SHA-1, SHA-256, and SHA-512 digest operations to DOCA SHA hardware. It covers dynamic engine loading, PCIe address selection, proof of actual offload, performance testing, and engine-versus-library selection. It is not intended for new SHA pipelines or for MD5, SHA-224, SHA-3, HMAC-SHA, or the stated incremental-hashing scenarios.
It guides users through checking DOCA and OpenSSL prerequisites, locating libdoca_sha_offload_engine.so, loading the engine with openssl engine dynamic, configuring the device with set_pci_addr, and using -engine_impl plus a SHA-224 negative test to verify that offload engaged. It also describes using openssl speed to compare CPU SHA with hardware offload across real message sizes, and helps select the ENGINE or the lower-level doca-sha library for a particular pipeline.
- A developer has a service using EVP_Digest and wants to offload SHA-1, SHA-256, or SHA-512 without rewriting it against the doca-sha C API.
- An operator runs openssl dgst and needs evidence that the digest was not silently computed by software.
- A performance engineer needs to measure the offload benefit across message sizes on BlueField or ConnectX hardware.
- A developer is deciding whether the existing OpenSSL ENGINE integration or a new doca-sha implementation is the better fit.
What are this skill's strengths and limitations?
- Designed for existing OpenSSL pipelines and avoids a full rewrite around the doca-sha C API.
- Covers engine loading, PCIe device selection, offload verification, and performance comparison.
- States the supported algorithms and the boundary between hardware offload and software fallback.
- Uses measurements on the user’s hardware to establish the message-size performance window instead of asserting fixed numbers.
- Only one-shot SHA-1, SHA-256, and SHA-512 offload is verified; MD5, SHA-224, SHA-3, and HMAC-SHA are outside scope.
- Not intended for new pipelines requiring fine-grained doca-sha control or partial hashing.
- Provides no samples, bindings, reference subtree, wrapper scripts, or fixed performance figures.
- The ENGINE API is deprecated in OpenSSL 3.x; the supplied material specifically records a verified surface for OpenSSL 1.1.1f and 3.0.2.
How do you install this skill?
Use the repository README’s CLI installation command: npx skills add nvidia/skills --skill doca-sha-offload-engine --yes. The compatible Agent can load the skill afterward. The guided engine workflow additionally requires the DOCA SDK, OpenSSL >= 1.1.1, libssl-dev or a distribution equivalent, and an accessible BlueField DPU or ConnectX NIC. Source builds use Meson, but the supplied material does not provide the complete build command.
How do you use this skill?
Ask the Agent for a concrete task such as: “Integrate DOCA SHA hardware offload into my existing OpenSSL pipeline on BlueField and prove that offload is active.” For an existing OpenSSL application, follow the guidance to load the dynamic ENGINE, set set_pci_addr, use -engine_impl where needed, and run the SHA-224 negative test and openssl speed comparison. For a new SHA pipeline, use the doca-sha skill instead; if DOCA is not installed or device access fails, route to doca-setup.
How does this skill compare with similar options?
For an existing OpenSSL pipeline where minimal change matters, use this ENGINE-oriented skill. For a new implementation or requirements such as partial hashing, custom buffer permissions, or capability queries, use the underlying doca-sha library instead.