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?
This is a very early stage TIP based on exploring SIV-based encryption tools in Threads.
What we’d need to provide/implement to support this stuff