Skip to content

Enhancement/security hardening - #329

Draft
PropzSaladaz wants to merge 22 commits into
developfrom
enhancement/security-hardening
Draft

PropzSaladaz wants to merge 22 commits into
developfrom
enhancement/security-hardening

Conversation

@PropzSaladaz

@PropzSaladaz PropzSaladaz commented Sep 17, 2026 •

Copy link
Copy Markdown
Contributor

Description

This PR includes several fixes / improvements regarding security.
Each issue has been solved separately in its own PR, and is linked below.

It also introduces several breaking changes with previous versions. Some compilation-wise (removed calls), others are more subtle and present under specific use cases.

Changes Included

1. #314 #313 Removal of unsecure fucntion exposed in the API

  • Library API calls BLSPublicKeyShare::VerifySigWithHelper and BLSPublicKey::VerifySigWithHelper were completely removed. Any calls to it will result in compilation failure. Update it to use VerifySig instead. Uses the same inputs.

2. #328 #330 Usage of AAD to derive IV for AES-GCM for deterministic encryption

  • ThresholdEncryption::encrypt() is now split into normal (non-deterministic) encrypt() and encryptDeterministic(). Callers that previously used encrypt() for determinstic encryption should update to encryptDeterministic()

  • Seed used for deterministic encryption was moved out of EncryptMetaData, and is now passed directly into the new method

  • EncryptMetaData additionally requires AesGcmVersion to be specified. Use V1 to keep legacy behavior, and V2 for new corrected behavior

  • This change does not affect the normal encrypt path ,since it doesn't use any synthetic IV, nor any validation path. Only affects the encryptDeterministic path.

  • Although the new functionality preserves deterministic behavior, it differs from the legacy encryptDeterministic for the exact same inputs. This means that distributed applications need to use synchronization to keep all encryptDeterministic callers either using V1 or V2. (updated to V0 and V1 in 3.)

3. #331 #332 Upgrade entropy from 128 bits to 256 bits for AESKey

  • Wire compatibility is one-way:

    • Historic V0 ciphertexts work with the new library.
    • New V1 ciphertexts do not work with an old V0-only library.
    • Consumers must therefore be upgraded before producers begin emitting V1 ciphertexts.
  • Existing high-level encrypt() and encryptDeterministic() call signatures remain unchanged, but their default output is now V1.

  • EncryptMetaData::aesGcmVersion has been replaced by EncryptMetaData::encryptionVersion. This prevents callers from selecting incompatible TE and AES-GCM combinations.

  • Direct AesGcmCipher users must update explicit enum values:

    • previous AesGcmVersion::V1 → new AesGcmVersion::V0
    • previous AesGcmVersion::V2 → new AesGcmVersion::V1
  • Distributed systems using encryptDeterministic() must pin metadata.encryptionVersion in their protocol or epoch configuration. Nodes using different profiles will intentionally produce different ciphertext bytes for the same seed and plaintext.

4. #333 #334 Reject any TE constructs using index 0

  • rejects 0 in TEPrivateKeyShare, TEPublicKeyShare, and TEDecryptionShare;
  • enforces the full 1..totalSigners range in TEDecryptSet;
  • adds a defensive zero-index check in lagrangeCoeffs;
  • updates affected tests and adds regressions.

@PropzSaladaz PropzSaladaz self-assigned this Sep 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant