1. The native Storj "uplink" command. Using this interface, a Go utility called uplink is run on the local client machine. It contacts a Satellite Node (the non-decentralized aspect of Storj) to retrieve a list of Storage Nodes that will accept the upload, then the file is split up and encrypted by the local uplink client code and sent to Storage Nodes recommended by the Satellite Node. In this case, the Satellite Node knows about the various pieces making up a file, the Storage Nodes have encrypted pieces of the file (but do not know how they relate to each other), and neither the Satellite Node nor the Storage Nodes could reconstruct the original file, even if working together, because the encryption key is stored on the local client machine only.
2. There is an S3 Gateway that gives Storj an S3-compatible interface. To use this, a Storj user would register a user account on the S3 Gateway, giving them an access key (login name) and secret key (password). When files are uploaded using the S3 Gateway, the access key and secret key are used to validate that the user has access to the specified bucket but there is no encryption happening. When data is received on the S3 Gateway, the Gateway uses the uplink technology to send split and encrypt the file and send the pieces to Storage Nodes. When a file is retrieved using the S3 Gateway, the Gateway does the reverse and sends the original, unencrypted file back to the S3 client.
Storj customers using the Storj network with the native Storj uplink client should have nothing to worry about as long as their local Storj key isn't disclosed.
For Storj customers using the S3 Gateway, it seems to me that by using data stored on the S3 Gateway, authorities could reconstruct files that were uploaded.
For HashBackup (I'm the author), both interfaces are supported, though the S3 interface is recommended. Since HashBackup encrypts everything locally before doing any uploads, backups stored on Storj using either interface cannot be reconstructed without a copy of the HB backup key, which is only stored on the local client machine, is not part of the backup data, and is never uploaded anywhere.
For our hosted S3 Gateway (called the Gateway MT), we have more details about how it works on this page: https://www.storj.io/disclosures, in the section titled "Encryption for Gateway MT"
The summary is that while the S3 gateway does have temporary access to unencrypted data during transit by protocol necessity, the S3 gateway does not keep the keys necessary to do this outside of the context of a request.
1. The native Storj "uplink" command. Using this interface, a Go utility called uplink is run on the local client machine. It contacts a Satellite Node (the non-decentralized aspect of Storj) to retrieve a list of Storage Nodes that will accept the upload, then the file is split up and encrypted by the local uplink client code and sent to Storage Nodes recommended by the Satellite Node. In this case, the Satellite Node knows about the various pieces making up a file, the Storage Nodes have encrypted pieces of the file (but do not know how they relate to each other), and neither the Satellite Node nor the Storage Nodes could reconstruct the original file, even if working together, because the encryption key is stored on the local client machine only.
2. There is an S3 Gateway that gives Storj an S3-compatible interface. To use this, a Storj user would register a user account on the S3 Gateway, giving them an access key (login name) and secret key (password). When files are uploaded using the S3 Gateway, the access key and secret key are used to validate that the user has access to the specified bucket but there is no encryption happening. When data is received on the S3 Gateway, the Gateway uses the uplink technology to send split and encrypt the file and send the pieces to Storage Nodes. When a file is retrieved using the S3 Gateway, the Gateway does the reverse and sends the original, unencrypted file back to the S3 client.
Storj customers using the Storj network with the native Storj uplink client should have nothing to worry about as long as their local Storj key isn't disclosed.
For Storj customers using the S3 Gateway, it seems to me that by using data stored on the S3 Gateway, authorities could reconstruct files that were uploaded.
For HashBackup (I'm the author), both interfaces are supported, though the S3 interface is recommended. Since HashBackup encrypts everything locally before doing any uploads, backups stored on Storj using either interface cannot be reconstructed without a copy of the HB backup key, which is only stored on the local client machine, is not part of the backup data, and is never uploaded anywhere.