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 不良研究所 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 不良研究所 to be zero trust and zero knowledge. Meaning, no entity (including 不良研究所) besides the data owner can ever access their data unless explicitly shared with others.
All of this adds up to 不良研究所 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 不良研究所. So, we felt it was worthwhile to compare 不良研究所 and S3 encryption offerings. We鈥檝e broken this topic into encryption capabilities, how encryption keys are handled, and access management. Here鈥檚 how 不良研究所 and AWS measure up.
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
不良研究所 does not have any mode of operations that isn鈥檛 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. 不良研究所 encryption has also been. Also important to note, our encryption at rest does not allow access by 不良研究所 employees. See documentation on 不良研究所鈥檚 encryption .
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 .
Encryption in transit
不良研究所 offers encryption of your data in transit by default. See documentation on 不良研究所鈥檚 encryption . 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 .
End-to-end encryption (E2EE)
不良研究所 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. 不良研究所 doesn鈥檛 just encrypt data end-to-end, but also metadata (like file names) to ensure full data privacy. See documentation on 不良研究所鈥檚 end-to-end encryption .
不良研究所 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 不良研究所. AWS does offer this, but it requires significant development work to implement and get them to the same level as 不良研究所 (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 不良研究所 user experience gives the customer complete control over encryption. 不良研究所 provides the customer the flexibility and control to generate or provide their own encryption keys鈥攌eys that 不良研究所 does not save or have access to. See documentation on 不良研究所鈥檚 encryption access controls .
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 and how to implement S3-SSE server-side encryption .
Vendor does not hold keys during upload/download
This feature is only offered in 不良研究所鈥檚 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 不良研究所, every customer provides their own encryption passphrase. In the 不良研究所 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鈥檚 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, 不良研究所 minimizes their own access to data and gives maximum protection to the customer even in the event of a breach. On 不良研究所, 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 不良研究所 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
不良研究所 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. 不良研究所 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 不良研究所鈥檚 access controls and .
Securely shareable WITHOUT vendor access
A unique feature of 不良研究所 is that you can share access without 不良研究所 having access from both the native protocol and our link sharing service鈥攎aking it fully private. Access sharing can either be through our primary native integration, in which 不良研究所鈥檚 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 不良研究所 servers never save, even in access logs. This gives you the confidence to share your private data, knowing that 不良研究所, nor anyone that you haven鈥檛 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 不良研究所鈥檚 native protocol, it cannot access any data nor metadata. 不良研究所 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. 不良研究所 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鈥攅ven 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 不良研究所 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 不良研究所'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鈥檚 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 不良研究所 customers coming from AWS is that they wouldn't call AWS's implementation of encryption tools "good support."
While I鈥檝e 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鈥檝e built their products just doesn鈥檛 natively support encryption the way that 不良研究所 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 不良研究所.
Security that comes at the expense of usability comes at the expense of security. 不良研究所 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 不良研究所. Because who has time to encrypt their data and build in the extra layers needed? 不良研究所 lets you skip that step and spend development effort on other value-add features.
