-
Notifications
You must be signed in to change notification settings - Fork 32
Asymmetric Keys
Asymmetric cryptography, also named public key cryptography, is widely used in encryptions and digital signatures. It split the key to two parts, the public key and the private key. User need to keep the private key secretly and share the public key to others. This makes key distribution easy and meanwhile introduces authentication feature to the cipher text.
In Ontology, as well as other blockchain systems, digital signatures are used to authenticate the constructor of transactions, check his right of the operation, e.g. transfer some funds to others.
ontology-crypto currently support following algorithms:
ID | Algorithm |
---|---|
0x12 | ECDSA |
0x13 | SM2 |
0x14 | EdDSA |
For exchanging keys between deferent process, an unified serialization format is needed.
The serialized public/private key has the following format:
algorithm_id || algorithm_parameters || key_data
The algorithm_id
is defined as the above, while algorithm_parameters
and key_data
are defined by each algorithm. Check pages of algorithms for details.
The private key is a sensitive data and should be stored securely. ontology-crypto uses a password based encryption scheme to protect private keys.
The encryption steps are as follows:
-
Derive a key from the password.
In this step, the scrypt function is used for derivation. Besides the password, the function also needs a salt, which is a 16 bytes array generated randomly. The salt should be stored together with the encrypted data and will be used to derive the same key in decryption process. Default parameters for the function are p = 16384, n = 8, r = 8, and the derived key length is fixed to 64.
-
Split the derived key to an encryption key and an initial vector.
Take the last 32 bytes of the derived key as the encryption key, and the first 16 bytes as the nonce. These will be used in AES encryption.
-
Use AES-GCM to encrypt the private key with the encryption key and nonce, with the address using as the additional authentication data(AAD). The 'address' here could be any string, while used in ontology, it is actually the account address. Padding is not needed since the GCM mode can process encryption as stream cipher.
It is needed to sort public keys in Ontology. The rules is as follows:
- if keys have different algorithm types, then sorted by the algorithm ID.
- else,
- ECDSA or SM2:
- if on different curves, then sorted by the curve ID.
- else if x values are different, then sorted by x.
- else sorted by y.
- EdDSA: sorted by the byte sequence directly.
- ECDSA or SM2: