Skip to content

v1.0.9

Choose a tag to compare

@cabelo cabelo released this 04 Jul 02:57
· 25 commits to main since this release

What's Changed

v1.0.9

New example

  • Added Node.js examples demonstrating the use of the main libzupt functionalities, making it easier to understand, validate, and integrate the library into new projects.

Security fixes: (Thank you all fixes @cristiancmoises )

  • Stop staging keys in predictable /tmp paths. The in-memory encrypt/decrypt path wrote the public key (and, worse, the private key) to /tmp/zupt_{pub,priv}_ just to hand a path to the file-based init functions. That was a symlink-attack vector and it defeated the library's own mlock protection by leaving private key material on disk. Added zupt_hybrid_encrypt_init_mem / zupt_hybrid_decrypt_init_mem, which parse the key straight from the caller's buffer; the C wrapper now uses them and never touches disk.

  • Create private key files with 0600 instead of the umask default. Applied to both the C path (zupt_hybrid_keygen, via open+fdopen) and the C++ path (KeyGenerator::saveKeyPair, via open+fchmod before the ofstream), so a freshly generated key is never briefly world-readable.

  • Fix sign-extension/UB when parsing the per-block payload length on decrypt. Each byte promoted to int, so byte << 24 is undefined and sign-extends when the top bit is set, yielding a bogus huge block_len. Cast each byte to size_t before shifting.

Cleanup:

  • Remove dead, incorrect zupt_hybrid_derive_keys (it ignored the X25519 shared secret and the ml_pk argument, so it produced keys the decrypt side could never reproduce) and the unused zupt_hybrid_decrypt_derive_keys.

Refactored the file-based init functions to share an encaps/decaps core with the new in-memory variants, so there is no duplicated KDF logic. Build is clean (no warnings) and all five test suites pass.