In most places where cryptographic hashes are required, we use the SHA-512/256 hash function as specified in FIPS 180-4.
All cryptographic signatures are made using the Ed25519 (pure) scheme specified in RFC 8032.
When signing messages and verifying signatures we require the use of a domain separation context in order to make sure the messages cannot be repurposed in a different protocol.
The domain separation scheme adds a preprocessing step to any signing and verification operation. The step computes the value that is then signed/verified using Ed25519 as usual.
The message to be signed is computed as follows:
M := H(Context || Message)
His the SHA-512/256 cryptographic hash function.
Contextis the domain separation context string.
Messageis the original message.
The Ed25519 signature is then computed over
NOTE: While using something like Ed25519ph/ctx as specified by RFC 8032 would be ideal, unfortunately these schemes are not supported in many hardware security modules which is why we are using an ad-hoc scheme.
All of the domain separation contexts used in Oasis Core use the following convention:
- They start with the string
- followed by the general module name,
- followed by the string
- followed by a use case description.
The maximum length of a domain separation context is 255 bytes to be compatible with the length defined in RFC 8032.
The Go implementation maintains a registry of all used contexts to make sure they are not reused incorrectly.
Chain Domain Separation
For some signatures, we must ensure that the domain separation context is tied to the given network instance as defined by the genesis document. This ensures that such messages cannot be replayed on a different network.
For all domain separation contexts where chain domain separation is required, we use the following additional convention:
- The context is as specified by the convention in the section above,
- followed by the string
- followed by the genesis document's hash.
There are currently two kinds of envelopes that are used when signing CBOR messages:
Single signature envelope (
Signed) contains the CBOR-serialized blob in the
untrusted_raw_valuefield and a single
Multiple signature envelope (
MultiSigned) contains the CBOR-serialized blob in the
untrusted_raw_valuefield and multiple signatures in the
The envelopes are themselves CBOR-encoded. While no separate test vectors are provided, those used for transactions can be used as a reference.