Thanks for asking. If you're interested, would be very happy to discuss SpiderOak's crypto strategy in depth with you the next time I'm in Chicago. Could shar

Thanks for asking. If you're interested, would be very happy to discuss SpiderOak's crypto strategy in depth with you the next time I'm in Chicago. Could share source code, etc. IMO, most interesting parts are the key scoping, which allow users to selectively publish ("share") portions of stored data by publishing the appropriately scoped keys. SpiderOak uses AES256 in CFB mode with authentication via HMAC. The code is careful about unique nonce/counter usage, crypto code is confined to specific modules that rarely change, and reviewed by cryptographers outside SpiderOak. Client and server have minimal trust relationship. Being paranoid about data integrity (not only because of crypto issues, but also because bitrot happens routinely at petabyte scale) the data authentication happens repetitively at a few different layers. From all end user devices, we see about one bit error per 4.2tb of upload transactions.