| Summary || Products || Cryptography || Fusion || KeeeX.Js || Verifier || KeeeX Chain || Digital Identity Management |
KeeeX relies on embedding metadata inside existing files, which is an active process.
There are three kinds of metadata embedded in files: integrity and authenticity content, extended metadata, and online references.
Various cryptographic tools are used at that point to produce verifiable proof of the data embedded in the file.
This also covers, to some extent, references to and from online services when applicable.
Ultimately, the validity of the embedded metadata can be verified by any third party knowledgeable in the used algorithms and tools.
To ensure robust support, KeeeX takes advantage of many standard algorithms.
This page describes the available algorithms and their general usage.
Note that most algorithms described here are either optional or default values.
Our software ensures that a minimum standard is met at any given time (forbidding the use of known weak algorithms), but users can specify different identifiers or algorithms in some cases.
KeeeX revolves around the concept of "IDX".
At its core, an IDX is a fingerprint of the data, using a custom representation to make it more legible for humans.
These IDX cover not only the original input data, but also the metadata embedded within the original data.
By using cryptographically secure hash algorithms, we then use these IDX as a substitute for the actual data in further processes such as digital signatures and other references.
The current default behavior of KeeeX Fusion is to use a method known as KeeeX Multihash for a document's IDX.
It is a custom chaining method that runs on the following two algorithms by default:
SHA3-256SHA2-256Additionally, a secondary identifier is embedded recursively in the files; the SHA2-256 of the IDX itself is computed.
This value is then present in both the file and the digital timestamp certificates (TSR, according to RFC3161).
It is possible to use SHA2-224 to create a separate identifier.
This remains an option for legacy use cases but is no longer recommended.
While the identifier value is the output of a digest algorithm, it is presented to the user (and stored in the file) using different encodings.
The main encoding for IDX is called bubble-babble.
It is a binary encoding that represents data using five-letter words that are always legible.
It is fully reversible and includes a level of error detection.
Alternative encoding for extra identifiers is available:
All currently supported digital signature algorithms use asymmetric encryption.
This means that they operate on two different keys:
In addition to these two concepts, KeeeX inherited the concept of "key address" from various blockchain-based solutions.
It is a third layer, beyond the public key, which provides a normalized means to identify a signatory's public key without disclosing this public key.
In practice, validating a digital signature using a key address is the same as doing so using a public key.
KeeeX Fusion is a low-level tool.
This means that the actual details of how a digital signature is produced, and how its digital identity is verified, are largely irrelevant to KeeeX Fusion.
Usually, a larger process involving KeeeX Fusion would be responsible for producing digital signatures and verifying digital identities, while Fusion itself would ensure that the embedded values are correct and valid upon verification.
The following digital signature algorithms are supported by our tooling:
| Algorithm | Size/Type | Built-in signature | Built-in verification | Digital identity informations |
|---|---|---|---|---|
| ECDSA (bitcoin & ethereum) | secp256k1 | Yes | Yes | Basic (Keeexed identity manifests) |
| X509-based ECDSA | Standardized curves only | Yes | Yes | Certificate chain (external validation required) |
| X509-based RSA | Common key sizes | Yes | Yes | Certificate chain (external validation required) |
Notes about this table:
The metadata model used by KeeeX allows the use of custom digital signature schemes as long as they follow some common properties:
Such custom digital signatures can be embedded in keeexed files, but their validity obviously cannot be verified by our Fusion tool.
In that case, they would be returned as-is, with a marker to indicate that they are not to be trusted automatically.
Most digital signature schemes operate on a limited input size for the message to sign.
The common practice is to compute a short, representative digest of the input message, which is then used as the input for the digital signature algorithm.
To this end, KeeeX uses three different message encodings:
SHA2-256 digest, for X509-based signaturesSHA2-256Keccak256 algorithmAll base signatures are performed on a message built using the signature's timestamp and the data's IDX, which is itself the output of the aforementioned procedure.
There are two main ways to embed a digital signature with KeeeX:
This ensures that private keys are kept as private as required in all scenarios.
In addition, since KeeeX Fusion usually operates on-premises, implementing mechanisms such as server signatures can be done seamlessly.
At the same time, end users can maintain control over their private keys.
KeeeX Fusion relies on some external services for specific operations:
SHA2-256 and digital signatures dependent on the service (usually ECDSA)