On 04/14/2014 08:17 AM, Adrin wrote:
>
>
> On Monday, 14 April 2014 03:11:04 UTC+2, Nikolaus Rath wrote:
> On 04/13/2014 01:46 PM, Adrin wrote:
> > Hi,
> >
> > I'm not sure if I understand it correctly, but is it true that you are
> > storing the AES key along with the data?
>
> Yes.
>
> > Then what's the point of encrypting the data in the fist place?
>
> The AES key itself is encrypted with a second AES key, that is not
> stored anywhere (unless you put it in ~/.s3ql/authinfo).
>
> The reason for having two separate keys is that it allows you to change
> your passphrase. If you would encrypt all the data with the passphrase
> directly, then in order to change the passphrase you'd have to download,
> decrypt, encrypt, and re-upload your entire file system.
>
>
> In contrast, if you have two keys (the "master" key that encrypts the
> data, and the "passphrase" that is used to decrypt the master key) all
> you need to do to change the passphrase is download, decrypt, re-encrypt
> and re-upload the master key.
>
>
> I came across this package because I wanted to protect my data not only
> from someone who's sniffing the network, but also the data storage
> provider itself. For this purpose, it doesn't make sense to give the
> encryption key to the provider.
Luckily, this is also not what S3QL does. Your provider is unable to
decrypt the data.
> With the current implementation, the
> only thing the provider needs to do is to brute-force my password.
Calling this the "only" thing is correct, but very misleading, because
no matter what you do, the only thing necessary to break any encryption
it is to brute-force the password. This is not at all specific to the
"current implementation" in S3QL.
> In order to protect my data against that, I will need to have a passphrase
> with the entropy of 256bits or more, to have an equivalent encryption
> power to a proper AES 256. And all of this, makes the second layer of
> the encryption useless.
I don't follow. Yes, your passphrase needs to have enough entropy, but
that holds no matter whether you use it to encrypt the master key, or to
encrypt the data directly. The use of the "second layer" is that it
allows you to change your password.
> I guess with the current status of the code, we can use it by only
> having a very strong passphrase, but it's doing lots of extra non-useful
> space on the server, as well as useless computation.
I have no idea what you are talking about here. The "extra non-useful
space on the server" is less than 1 kB. The "useless computation" has to
be performed once when mount.s3ql starts, and probably takes less than
100 microseconds on a modern computer.
> Could we add a feature to the code to read the key from the client
> instead of the server?
Unless you make a much better case for this feature, I'm afraid the
answer is no. As far as I can see, there is absolutely no reason to do
this, and lots of reasons not to do it that way.
Best,
Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
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.
