Data protection is extremely important for applications today. Regulations continue to be added and the last thing a company needs is to be tied up with violations. When we designed Storj decentralized object storage, data security and privacy were at the forefront of our requirements.
Part of this is simply the nature of decentralization. We had to make data transfer and storage trustless as it was the only way to have third parties with excess storage capacity integrated together without security concerns. So, we architected Storj to be zero trust and zero knowledge. Meaning, no entity (including Storj) besides the data owner can ever access their data unless explicitly shared with others.
All of this adds up to Storj being an extremely secure cloud storage provider. Other cloud providers don't offer nearly the same level of security that we do. For example, AWS didn't make encryption at rest available by default until recently. This means your data was stored unencrypted by default next to everyone else's data in S3.
Even with the added encryption for data at rest, customers tell us that better security is one of the key reasons they switch to Storj. So, we felt it was worthwhile to compare Storj and S3 encryption offerings. We’ve broken this topic into encryption capabilities, how encryption keys are handled, and access management. Here’s how Storj and AWS measure up.
And if you want even more details, join Storj Chief Architect, JT Olio, for a deep dive webinar on this topic.
Comparing encryption capabilities
Encryption of data in transit has been a common standard in cloud storage. Now that AWS S3 has added encryption of data at rest, these two features combined are the expectation in cloud storage. That said, end-to-end encryption is not possible with any of the hyperscalers unless the customer encrypts their data prior to upload.
Encryption at rest
Storj does not have any mode of operations that isn’t secure. Our implementation is open source and you are free to inspect, compile, etc. so you do not have to trust us that it is correct. Storj encryption has also been audited by Atredis Partners. Also important to note, our encryption at rest does not allow access by Storj employees. See documentation on Storj’s encryption here.
AWS implemented encryption of data at rest in early 2023. While they now encrypt your data at rest, even when encrypted Amazon has the keys so they still have access to your data. This also means that any vulnerabilities or defects in their closed source code could expose your data. See S3 encryption at rest documentation here.
Encryption in transit
Storj offers encryption of your data in transit by default. See documentation on Storj’s encryption here. In comparison, AWS S3 provides instructions for extra configuration using the HTTPS protocol to make encryption in transit a default. This is important because very early releases of S3 did not even support HTTPS. See documentation on making encryption in transit a default on S3 here.
End-to-end encryption (E2EE)
Storj was designed to work with end-to-end encryption from its inception. The only way to accomplish this on AWS is if the user encrypts their data themselves before uploading to AWS. Storj doesn’t just encrypt data end-to-end, but also metadata (like file names) to ensure full data privacy. See documentation on Storj’s end-to-end encryption here.
Storj offers these encryption capabilities by default and does not let you use any methods that are not encrypted in transit or at rest. This means less work to keep your data secure.
How encryption keys are handled
Using customer-chosen encryption keys is a standard offering with Storj. AWS does offer this, but it requires significant development work to implement and get them to the same level as Storj (e.g., this feature is not available for many of their provided programming language specific SDKs). With AWS, the burden is on the customer to customize their tools to use their own keys and/or encrypt their data.
Vendor does not hold at-rest keys
By default, the Storj user experience gives the customer complete control over encryption. Storj provides the customer the flexibility and control to generate or provide their own encryption keys—keys that Storj does not save or have access to. See documentation on Storj’s encryption access controls here.
The default SSE-S3 does not allow customers to choose encryption keys. The SSE-C product gives you the option to have a customer-provided encryption key, but the feature would require heavy lifting to implement and development work to figure out how to do this per object. Also note that AWS specifically says they do not encrypt the metadata when you use this feature. See documentation on how AWS implements encryption keys here and how to implement S3-SSE server-side encryption here.
Vendor does not hold keys during upload/download
This feature is only offered in Storj’s native protocol by default. Most S3 clients do not support client-side encryption, so end-to-end encryption isn't typically an option. If yours does, you may always double-encrypt.
Every object encrypted uniquely and automatically
With Storj, every customer provides their own encryption passphrase. In the Storj client software, we use this passphrase along with project specific cryptographically random seed material to securely generate project-specific and object-specific keys that never leave the client software. These keys are then used to encrypt object-specific metadata like names. The data for each object is encrypted with a unique key generated for that object. The decryption key for that object is one of the values stored encrypted by the object specific key. This scheme may sound complex, but it allows for two desirable features: (1) data and metadata cannot be recovered without the customer’s key, even if the provider wants to, and (2) the customer can share individual objects or collections of objects without revealing the decryption material for more objects than they specified.
By using customer-chosen encryption keys in this way, Storj minimizes their own access to data and gives maximum protection to the customer even in the event of a breach. On Storj, these features are easy to use and supported by default, not an obscure corner of the product. Any encryption feature that requires extra development work is much less likely to get used.
How access management is implemented
There are some security measures that Storj decentralized storage has that no other cloud provider does. Secure and private access management is a key difference. AWS has full access to your content and uses a central access control list by default. It is only in SSE-C and when using client-side encryption that customers have any measure of access control.
Decentralized, capability-based access control
Storj combines authorization and encryption management using Access Grants. An Access Grant is an envelope with everything an application needs to locate an object on the network, access that object, and decrypt it. The key benefit of this approach is that these Access Grants and any associated restrictions can be entirely managed client-side, without a central access control list or other server-side mechanism involved in the access management process. Storj enables access restrictions to be encoded into the API key. Caveats can restrict whether an Access Grant can permit read, write, delete, or list. Caveats can also restrict operations on buckets, specific paths, or within time windows. See documentation on Storj’s access controls here and here.
Securely shareable WITHOUT vendor access
A unique feature of Storj is that you can share access without Storj having access from both the native protocol and our link sharing service—making it fully private. Access sharing can either be through our primary native integration, in which Storj’s servers never see the keys, data, or metadata, as with any other standard access, or through our link sharing browser gateway, in which access is a key encoded in the URL, which Storj servers never save, even in access logs. This gives you the confidence to share your private data, knowing that Storj, nor anyone that you haven’t explicitly authorized by giving them the key, can access your data.
Vendor has NO access to sensitive file name and other metadata
It is important to note the differences in the way that encryption is implemented. One of those big differences is data privacy. With Storj’s native protocol, it cannot access any data nor metadata. Storj can only temporarily access these things if the user gives permission out of necessity by registering with our S3 gateway or our link sharing service, linkshare. Alternatively, AWS always has access to your sensitive data unless you are encrypting it before upload.
Most cloud providers have made business decisions not to provide better security because they would have to start over. Storj strongly believes that encryption should be as easy as possible to use and well-supported out of the box. And if you want all the benefits of our native protocol, but still want the ease of use and compatibility of the S3 API, then you can use the self-hosted gateway. And that it should truly be end-to-end to be as secure and private as possible.
What cloud providers can see—even with encryption.
Data protection is not just about security, it is also about data privacy. One of the key differences throughout this comparison is the fact that no one on the Storj network has access to your data. On AWS and other cloud providers, they can see your metadata, they can access your data. That is not data privacy.
Other cloud providers at their absolute best still fall short of Storj's default security posture. Providers like Amazon want to be your competitor, so why give them access to your businesses most important data? Why give them access to your data when even your employees do not have access? We have eliminated the possibility of even eliminating your privacy. Private by default, because defaults matter.
Who has time for data encryption?
Out of the box, the AWS S3 encryption looks decent. But in practice, implementing it is hard. It’s a common sentiment thrown out in the developer communities that "you should just encrypt your own data before you send it to Amazon if you care." Of course hardly anyone does this unless the tool has good support for it. And everything from my own experience and that of Storj customers coming from AWS is that they wouldn't call AWS's implementation of encryption tools "good support."
While I’ve focused on AWS in this article, the fact is that GCP and Azure and the rest of the centralized cloud providers are the same on encryption. The way they’ve built their products just doesn’t natively support encryption the way that Storj does. They are limited by that design and would need to completely rebuild their products to get the same level of data protection as you get on Storj.
Security that comes at the expense of usability comes at the expense of security. Storj made security easy to use by default. And that is a big reason why developers working on products where data protection is important are moving to Storj. Because who has time to encrypt their data and build in the extra layers needed? Storj lets you skip that step and spend development effort on other value-add features.
Want a deeper dive on this topic? Join Storj Chief Architect, JT Olio on a webinar addressing this topic at a developer level. Join the webinar.
