TIP 003: Deterministic Encryption
Opened this issue · 0 comments
carsonfarmer commented
This is a very early stage TIP based on exploring SIV-based encryption tools in Threads.
- It looks like AES-GCM-SIV is the most promising (upcoming) solution.
- It protects against nonce-reuse to some degree, thus providing a way forward for deterministic encryption schemes
- However, there are some limitations
- You can’t just use the same nonce all the time, but you could probably use the same nonce for each thread
- It is relatively new, and while no known vulnerabilities exist, this is early days
- There are very few software implementations
- Here’s a Go lang version and here’s the reference implementation
- It is implemented by default now in Google’s BoringSSL, so there may be golang versions out there soon. It is also likely available via nodejs in electron… but likely not in the browser any time soon
- This is most promising cross-language implementation, but it doesn’t provide AES-GCM-SIV per se (yet), but the variants it does provide are pretty good (see this comparison), and it works in the browser
- Bonus, the javascript implementation is written in Typescript
What we’d need to provide/implement to support this stuff
- I think it’d have to be optional… there is risk and possible leakage (though minimal) of information
- I think we’d have to implement some type of ‘multicipher’ protocol similar to a ‘multihash’, so that our system would know which type of encryption we are dealing with. I don’t think we want to only store this information in the thread dag, as it would be good to be able to ‘turn on and off’ certain types of encryption. Similarly, it is sometimes useful to extract encrypted files outside of the context of the thread. It seems like there is already external work in this area, and maybe @sanderpick already knows how IPFS is managing in-lining of crypto information in keys?
- We’d have to decide how to manage the nonces. I’d suggest that we do use a thread-specific nonce, but then we might want to think about regular key rotation or something? Depending on use cases, it might also be possible to use a single nonce per top-level thread item, and then reuse the nonce only for ‘nested’ files or files that ‘target’ that given top-level item?