Cryptographic software must evolve. CipherDrive™ therefore uses a protocol-versioning approach so that newer clients can improve security and compatibility without assuming that every encrypted object was created using exactly the same format forever.
Protocol versioning can allow Ackaia to:
improve key-derivation parameters;
add stronger metadata authentication;
migrate encryption formats;
support new sharing models;
improve browser compatibility;
preserve compatibility with older encrypted files;
deprecate weaker legacy formats.
An encrypted payload or its metadata can include a protocol version so the client knows which rules to apply when decrypting it.
For example, a version can determine how a key was derived, how metadata is authenticated, which fields are present, or which IV construction is expected.
Where possible, Ackaia may design newer clients to:
decrypt older supported formats; and
encrypt newly created content using the latest protocol version.
This is a common way to improve security gradually without forcing every historical object to be rewritten immediately.
An updated client can include:
stronger cryptographic parameters;
security fixes;
new protocol support;
legacy-format migration logic;
browser compatibility improvements.
Using an obsolete client can prevent you from benefiting from newer protections and may eventually reduce compatibility.
Ackaia may deprecate older formats when maintaining them would create unacceptable risk. The exact migration path depends on the protocol and product state.
Where migration is required, the client may need valid access to the old cryptographic material before it can safely re-encrypt or rewrap content into a newer format.
CipherDrive may include protocol version information in Additional Authenticated Data. When that happens, the version is not secret, but it becomes cryptographically bound to the ciphertext so that changing it causes authentication failure.