Team Compute uses different Public Key Cryptography systems (NaCl, RSA, ECDSA) in different layers.
1. NaCl Public Keys
NaCl is used to protect Dynamic Aliases, each alias comes with at least 2 set of keys for encryption and signing:
public encryption key
private encryption key
public signing key
private signing key
Please refer to the NaCl section for enhancements Team Compute made to a popular NaCl library.
2. RSA Public Keys
RSA is mainly used for communication between servers under the TLS protocol. Since the default library (NaCl) is already using elliptic curve at the data transaction level, we wrap them up inside the different RSA encryption for extra protection at the server transaction level.
The public key cryptography system for the HTTPS transport is RSA based with 2048-bit keys for HTTP Servers (from Let's Encrypt) and 4096-bit keys for HTTP Clients.
3. ECDSA Public Keys
ECDSA is used in some of Private Cyberspace functions like Fuzzy Blockchain (which is based on Bitcoin Core), it complements the EdDSA used in the default NaCl library.
The public key cryptography system for the blockchain storage is ECDSA based with 256-bit keys (from the Bitcoin Core).
4. Future Public Key Systems
For future versions of the platform, we are investing quantum-resistant cryptography (e.g. using OQS instead of RSA in the Networking layer).
The preference is to always have different public key systems handling the Processing, Networking and Storage layers.
NaCl is currently the default general purpose encryption library used by Team Compute. It is used extensively as an extra layer to complement traditional RSA based encryption.
For example, most data messages in Sovereign Transactions are encrypted with NaCl 256-bit keys.
A popular javascript implementation of NaCl called TweetNaCl.js is used as the base:
Added Nonce Prefix
always insert nonce before ciphertext for easy decryption
Default Random Nonce
automatically generate a secure 24 byte random nonce if none is supplied
Added REST API
so non javascript programs e.g. php, shell can also make us of it
Note some limitation of TweetNaCl.js:
Although TweetNaCl.js has passed an audit by Cure53 in 2017, it does has some limitations that should be kept in mind:
Secret Key Commitment
While XSalsa20-Poly1305, as used in nacl.secretbox and nacl.box, meets the standard notions of privacy and authenticity for a secret-key authenticated-encryption scheme using nonces, BUT it is "not key-committing", which means that it is possible to find a ciphertext which decrypts to valid plaintexts under two different keys. This may lead to vulnerabilities if encrypted messages are used in a context where key commitment is expected.
Signature Malleability
While Ed22519 as originally defined and implemented in nacl.sign meets the standard notion of unforgeability for a public-key signature scheme under chosen-message attacks, BUT it is "malleable", so given a signed message, it is possible, without knowing the secret key, to create a different signature for the same message that will verify under the same public key. This may lead to vulnerabilities if signatures are used in a context where malleability is not expected.
Hash Length-extension Attacks
The SHA-512 hash function, as implemented by nacl.hash, BUT it is "not resistant" to length-extension attacks.
Side-channel Attacks
While TweetNaCl.js uses algorithmic constant-time operations, BUT it is impossible to guarantee that they are physically constant time given JavaScript runtimes, JIT compilers, and other factors. It is also impossible to guarantee that secret data is physically removed from memory during cleanup due to copying garbage collectors and optimizing compilers.