Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TIP 003: Deterministic Encryption #75

Open
carsonfarmer opened this issue Dec 17, 2019 · 0 comments
Open

TIP 003: Deterministic Encryption #75

carsonfarmer opened this issue Dec 17, 2019 · 0 comments
Labels
TIP Threads Improvement Proposal

Comments

@carsonfarmer
Copy link
Member

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?
@carsonfarmer carsonfarmer added the TIP Threads Improvement Proposal label Dec 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TIP Threads Improvement Proposal
Projects
None yet
Development

No branches or pull requests

1 participant