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:
-
Secret Key Commitment
While XSalsa20-Poly1305, as used innacl.secretbox
andnacl.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 innacl.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 bynacl.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.
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:
- public encryption key
- private encryption key
- public signing key
- 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.