Technical FAQ

Measurement scope, package boundaries and deployment interpretation.

A single reference for the qualifications and limitations that apply across the RSA-oriented and ECC-oriented technology pages.

How to read the evidence

Specific measurements, explicit boundaries.

Technical results are meaningful only with their source revision, compiler, profile, target and test method. This page centralizes the interpretation rules so the technology and kit pages can focus on their engineering content.

01

Do the published measurements constitute an independent security audit or certification?

No. The reported workflows provide reproducible engineering evidence for the tested source revision, compiler, profile, platform and measurement budget. The corresponding automated qualification and binary-hygiene workflows executed in GitHub Actions passed their predefined gates. These results do not constitute an independent security audit, FIPS validation, Common Criteria evaluation, cryptographic certification or production approval.

02

Are the benchmark figures universal performance claims?

No. Timings, RSS, Flash, stack and workspace values remain attached to the named build and execution conditions. They characterize reproducible profiles and do not establish a universal ranking of algorithms. Independent benchmarking on the intended platform remains appropriate before production use.

03

What do the RSA and ECC dudect results establish?

They are bounded statistical timing-leakage diagnostics. The RSA campaign executed the selected fixed-size kernel approximately 34 million times and recorded a maximum absolute Welch t-statistic of 4.27, within the predefined |t| < 4.5 gate. The integrated ECC v1/v2 campaign completed 36 of 36 passing tests over 3.6 million effective measurements, with maxima of 3.97 and 4.15, within the predefined |t| < 4.5 gate. Although all campaigns passed their predefined numerical gates in automated workflows executed in GitHub Actions, this does not constitute certification.

04

What does QEMU-based embedded evidence mean?

QEMU demonstrates functional execution, package retest behavior and the configured stack-painting and binary properties. The target-specific automated embedded qualification workflows executed in GitHub Actions passed their defined QEMU functional, package-retest and binary/resource gates. This is not physical-device timing, power, energy, electromagnetic, fault-resistance or certification evidence, and it is not a certified interrupt-inclusive worst-case stack bound.

05

Can hosted process RSS be compared directly with embedded RAM?

No. Hosted RSS includes the executable, loader, runtime, libraries and process effects. Embedded measurements separate Flash, painted stack, fixed workspace, static data and measured heap. Values from these evidence tracks must not be added or treated as interchangeable.

06

What is the difference between Evaluation and Integration Kits?

Evaluation Kits are binary-only black-box packages intended for controlled execution, inspection and evidence reproduction. Integration Kits add the approved public headers, linkable libraries, examples and customer-side compile/link checks. Production permission and source access are separate written matters.

07

What is the difference between Advanced and Binary Footprint Integration Kits?

The Advanced Integration Kit is the canonical Core + RSA Advanced customer distribution. RSA Binary Footprint Integration Kits expose specialized Embedded Lean or Edge OpenSSL boundaries for resource and dependency assessment and are not substitutes for the full Advanced API distribution.

08

How do OpenSSL external-runtime and self-contained packages differ?

External-runtime packages use an architecture-compatible customer-supplied libcrypto runtime. On Windows, the directory containing the matching DLL must be on PATH. Self-contained packages bundle the approved libcrypto runtime, licence and checksums. Neither package line requires libssl.

09

Which OpenSSL version lines are available?

The current v0.2.0 kit matrix uses the qualified OpenSSL 3.5.7 and 4.0.1 lines, with external-runtime and self-contained boundaries where applicable. Previously qualified OpenSSL 3.0-based v0.1.7 kit lines remain available on request according to their original platform and profile scope; they are not relabelled as v0.2.0 packages.

10

Are ECC v1 and ECC v2 interchangeable?

No. They share the frozen Commercial ECC C API v1 but are different fixed-domain binary products. Public-key blobs are generation-bound, both peers must use the same generation and private scalars must not be reused across domains.

11

What remains outside the public website and customer binaries?

Proprietary implementation source, private headers, internal Field256 and GLV controls, non-public domain material, reserved workflows, test corpora, secrets, private keys and internal diagnostics remain outside the public boundary unless a separate written agreement explicitly provides otherwise.

12

What is required before production or regulated deployment?

The intended environment requires its own security review, target-specific validation, entropy and key-management assessment, integration testing and any certification or regulatory work applicable to the product. Independent benchmarking and cryptographic validation remain appropriate before production use.

Technical brochure

Review the RSA-oriented and ECC-oriented technologies in one concise document.

Download technical brochure