v15.0.0

[15.0.0] - 2025-03-13

🚀 Features

• Add partial coordinates: Partial coordinates allow ciphertexts created with
  an access policy "D1::A" not to be invalidated upon addition or deletion of
  another dimension/attribute.

• Hardened cryptographic primitives: Covercrypt is now CCA-secure, with an
  improved resistance against timing attacks thanks to shuffling.

• Toward cryptographic agility: elliptic curve (as of now only the Ristretto
  form of the X25519 and P256 are available) and MLKEM security levels can be
  selected using features. The modular architecture allows to easily add new
  implementations. However the modularity is not trait-based but feature-based,
  prohibiting the instantiation of several coexisting flavors of Covercrypt.

• Lighter encapsulations: we decided to optimize encapsulation sizes at the
  cost of user-secret-key size since encapsulations are generally more numerous
  than user secret keys. In particular, it is now possible to efficiently create
  broadcast encapsulations for any valid combination of attributes

• Interface standardization: Covercrypt now exposes both a KEM and a PKE
  interface, both providing 128 bits of both pre- and post-quantum CCA security.

• Interface simplification: the policy object is now an internal detail of the
  MSK and needs not be passed to the Covercrypt API (which improves security by
  preventing de-synchronization between the policy and the master keys).

Breaking changes

1. Serialization of all Covercrypt objects has been modified, which makes
   previous serialized objects incompatible.

2. The policy was renamed access structure to avoid confusion with an access
   policy.

3. Access policies are parsed using a different set of rules:

   • "*" stands for all the rights when used to generate a USK and any
     right when used to generate an encapsulation;
   • "D::A" stands for any combination involving the "A" attribute from the
     dimension "D";

   Therefore an encapsulation generated under the "D1::A && D2::B" access policy
   can be opened by user secret keys generated for the "D1::A || ...", "D2::B ||
   ..." or "D1::A && D2::B || ..." (as was already the case), and an
   encapsulation generated under the "D1::A" access policy can be opened by a
   user secret keys generated for the "D1::A && ..." access policy.

Bug Fixes

• [breaking] Rename from_boolean_expression into parse

v14.0.0

[14.0.0] - 2024-03-07

Features

• Change Axis to Dimension with a clear distinction between Ordered and Unordered.
• Create a Dictionary data structure to store and update Ordered Dimension efficiently
• Change the data structure of MasterSecretKey and UserSecretKey to keep track of subkeys version.
• Policy does not count the attribute rotations anymore as they are stored in the subkeys.
• a UserSecretKey can now be refreshed without any external Policy information.
• Internalize Policy parsing method from the KMS to improve encapsulation.

v13.0.0

[13.0.0] - 2023-11-06

Bug Fixes

• KMAC compute deterministic & Policy edit edge case (#117)

Features

• Add KMAC to attest the authenticity of user keys (#114) and make policy editable (#115):

  • In Covercrypt, we have the following properties:

    the number of attribute values grows with the number of attribute modifications performed: rotations add a new value for an existing attribute while attribute creations add a new attribute with a new value;
    the number of partitions is equal to the number of combinations of attribute values that can be created by using one value associated to an attribute from each axis;
    the number of keys in each master key is equal to the number of partitions that can be created using their associated policy.

  • Hence, if a great number of attributes are created or a great number of rotations are performed, the size of both the policy and the master keys will grow drastically.

  • To prevent this, we need to allow dropping attribute values from the policy:

    removing an attribute from a policy axis could prevent the number of attributes from growing too big;
    retaining only a given number of values per attribute could allow purging the policy from old rotated attribute values.

  • Then a master key update should synchronize the master keys with the updated policy.

  • Note: this is not a problem for user secret keys since they generally hold a small subset of the policy rights; they also can be purged from old sub-keys at each refresh by setting the keep_old_rights parameter to false which prevents rotations from rendering them unmanageable.

v12.0.3

feat: support crypto_core 9.2.0

v12.0.2

feat: Update crypto_core to 9.1.0

v12.0.1

fix: patched kyber seed security issue

v12.0.0

feat: use CryptoCore v9.0, update namings in paper and harden zeroiza…

v11.0.2

fix: bump Cargo.toml version to 11.0.2

v11.0.1

feat: update readme fixing formulas and upgrade crypto_core

v11.0.0

refactor!: move all interfaces (FFI, Wasm, pyo3) to cloudproof_rust r…