Below is my comment on Azure Storage issue, which was msft-removed.
@pemari-msft MS approach to client-side encryption in Azure Storage is somewhere between ignorance and incompetence. @GrabYourPitchforks is probably your best MS resource, but let me explain the problem anyway.
Why is client-side encryption useful? What value does it provide, and what threats does it deter?
- "encryption-at-rest", which is often a regulatory requirement (server-side encryption achieves it as well)
- Defense against lack or lapses in confidentiality of Azure storage or/and Azure transit (HTTPS/TLS)
- Defense against lack or lapses in integrity of Azure storage
Azure Storage security guide makes it clear that data integrity is of utmost concern, just like data confidentiality is. At the same time, client-side verification of data integrity is not "checking that the MD5 hash of the data matches its MD5 metadata" (which provides no integrity guarantees even with a non-broken hash alg), and it's not "relying on TLS to guarantee that the Azure-tampered data reaches the client with full in-transit integrity".
Saying "but isn't TLS enough?" when discussing client-side encryption is sheer ignorance of why client-side encryption is needed to begin with.
What really takes the cake, though, is that MS has shipped client-side encryption without client-side integrity validation. That shows incompetence, which no amount of "we have plans to implement AES-GCM at some point in the future" can justify.
You don't need AES-GCM to provide client-side integrity validation – EtM with AES and HMAC-SHA2 will work on every platform.
It's not a "custom" client-side encryption implementation that Azure Storage needs, but a proper and secure one.