On Sun, Jul 20, 2014 at 1:22 PM, Nikolaus Rath <[email protected]> wrote:
> Mark Mielke <[email protected]> writes: > > Presuming I understand how it works... I think having AWS perform the > > encryption partially defeats the purpose of encryption. > [..] > > Oh, absolutely. S3QL would continue to do client-side encryption as > before. The question is: is there any good reason to activate (or not > activate) server-side encryption *in addition* to that. > > I am very irritated by this feature for the same reasons you mentioned > above. It doesn't seem to add any value, but it doesn't seem to have any > drawbacks either. So why is Amazon even requiring a choice at all? Ok. I see your thinking now. I believe the primary use case for server-side encryption of S3 objects is server-side encryption only, and not client-side + server-side encryption. So, part of the reason why s3ql doing both client-side and server-side might seem without value, is because I think it isn't the use case that the solution is designed for. See: http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html "Server-side encryption is about data encryption at rest—that is, Amazon S3 encrypts your data as it writes it to disks in its data centers and decrypts it for you when you access it. As long as you authenticate your request and you have access permissions, there is no difference in the way you access encrypted or unencrypted objects. Amazon S3 manages encryption and decryption for you. For example, if you share your objects using a pre-signed URL, that URL works the same way for both encrypted and unencrypted objects." >From their examples, I see two use cases listed: 1) You have network bandwidth, but you don't have CPU resources to encrypt the data. An example of this is probably AWS-on-AWS where you have to pay for EC2 compute resources, and since the data is already on EC2 in un-encrypted form you could argue that it may as well be un-encrypted in transit as well, as long as it gets encrypted at rest. This use case seems like it may be relevant to S3QL users, although I've not personally found encryption to be a bottleneck for my use cases so far. 2) You want per-object encryption at rest, where you can send the encryption key to another party, and allow them to easily access the data without having encryption software installed. "if you share your objects using a pre-signed URL..." I don't see this one as relevant to S3QL users as S3QL would maintain the database of per-object encryption keys and you wouldn't normally share a single object at a time. For use case 1), I'm starting to come around to it providing value, and it may be that my limited use of S3QL has been for backups from my home machine, that I think 1) is not applicable as I don't trust the data in transit (Internet provider, and all the hops between them and Amazon...). But, if I was sending from AWS to AWS, I might come to a different conclusion. -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
