Multilevel Public Key Cryptography

Private Cyberspaces use different Public Key Cryptography systems (NaCl, RSA, ECDSA) in different layers of the platform to prevent the cracking of one bringing down the whole platform.

1. NaCl

NaCl is currently the default general purpose encryption library used in Private Cyberspace. For example, most data messages in Sovereign Transactions are encrypted with NaCl 256-bit keys.

A popular javascript implementation is TweetNaCl.js:

Some limitation of TweetNaCl.js:

  1. 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.

  2. 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.

  3. Hash Length-extension Attacks
    The SHA-512 hash function, as implemented by nacl.hash, BUT it is "not resistant" to length-extension attacks.

  4. 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.

1.1. Public Keys

One major use of NaCl is on the protection of Dynamic Aliases, each alias comes with at least 2 set of keys for encryption and signing:

  1. public encryption key
  2. private encryption key
  3. public signing key
  4. private signing key

Public Key Demo

1.2. Secret Keys

By default the Secret Keys are NaCl based:

Secret Key Demo

1.3. Enhancements

More NaCl implementations only have Box and Secret Box, all Private Cyberspace implementations support Sealed Box also, enabling encryption and decryption easily with just one key (public or private).

2. RSA

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

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.