a laser focused port of crypto sealed box encrypt/decrypt, ed25519 sign/verify, and ed25519 to curve25519 functionality from libsodium
- TARTLE stores 64 byte ed25519 verify keys used as a psuedononymous identifier and to verify transaction signatures
- TARTLE stores 64 byte ed25519 signing keys, encrypted using AES256 plus a SHA256 hashed pin/password unknown to TARTLE
- TARTLE verifies stored financial transaction signatures on behalf of users using ed25519 verify keys
- TARTLE encrypts arbirary data for storage using curve25519 public keys derived from the ed25519 verify key
- TARTLE decrypts arbitrary data on behalf of using using curve25519 private keys derived from the ed25519 signing key
Currently, encryption, decryption, and signing occur server side. This means that TARTLE must be a trusted entity in any transaction between two separate parties (eg, selling your data to a buyer).
We would like to move to a model where encryption, decryption, and signing occur client side, meaning that TARTLE serves simply as a storage mechanism of public key/encrypted private key pairs, and encrypted data for transfer. We advocate for this model of data transfer wherever a third party is responsible for storing or transferring data which it has no inherent interest in.
The canonical example of this is illustrated by your bank's collection of your social security number. The bank has no interest in your social security number, and has no need for it beyond transferring it to relevant tax authorities. At the time you provide your social security number to the bank, it should be encrypted by you, using only the public keys corresponding to the end-consumer of the data. In this case, the IRS and or a state taxation authority. We believe storing and transmitting data in this way greatly reduces the possibility of sensitive data leaks as the data need not be stored in plaintext by all who transmit it. It also gives fine grained control to the owner of data since sharing is explicitly limited by the public keys used to encrypt it.
Initially, we will separate functionality into separate files inside a dedicated folder called /research aligning with the source files in libsodium. Each file will contain the c source for the function from libsodium in a comment at the top of the file with a permalink to the libsodium github library source. Below this will be various existing javascript implementations where they exist, along with permalinks to source code.
The intention will be to determine if any of the existing javascript functions can be used as-is, and if not, comment on issues with them.
Finally, after we have determined appropriate implementations for each function, we will combine them into a module which can be used by browsers in the /src folder.