Encrypted messages #17
Description
Encryption is currently out of scope and needs to be done in a different layer if needed by encrypting the data before passing it to tr1pctl write. Since the blocks need to be decryptable in the future we can't apply forward secrecy, but having regular public key encryption built in might be useful and possibly a common usecase. The following scenario seems likely:
A sensor should be able to write an encrypted log which itself can verify, but can't actually read. To read the log, it needs to be transfered to a different, trusted system that has the private key that is needed to read the messages contained inside the blocks.
This would require a change to the file format, but I'm not yet sure how this would look like in detail. There could be a field in the block that identifies which publickey has been used so the trusted system can select the right private keys if it has multiple private keys. I'm not sure if encrypting to multiple public keys should be implemented.