[dm-crypt] LUKS overhead?
ryan.nix at gmail.com
Tue Sep 9 21:12:15 CEST 2014
Halo, Ralf! Thank you for the quick response as well as the insight into
using LUKS. Ideally, we would prefer ownCloud's method of encryption,
however, the dramatic increase in file size threw us for a loop. We also
wrote a custom ownCloud app to convert video files with ffmpeg but
ownCloud's documentation on how to work with encrypted files is spotty at
best. Our researchers have strict requirements for protecting their data,
so encryption at rest is needed in some basic capacity. I realize the
implications of the web server having access to the files, but we might
have to use LUKS in the initial rollout until the ownCloud developers can
change the encryption scheme to be more efficient.
On Tue, Sep 9, 2014 at 12:32 PM, Ralf Ramsauer <
ralf+dm at ramses-pyramidenbau.de> wrote:
> Hi Ryan,
> On 09/09/14 18:11, Ryan Nix wrote:
> > Can anyone tell me if we'll see the same kind of increases in file
> > size? I ask because we're trying to plan on how much storage we
> > should buy.
> There will be no increase of the size of 'files'.
> Luks resp. dm-crypt is just a layer between block devices and actual
> So the actual size of files depends on your filesystem and not on luks
> or dm-crypt.
> Dm-crypt uses blockciphers. In short words that means that x byte
> plaintext will be encrypted to x byte ciphertext, without any overhead
> or increase of size.
> I don't know how owncloud's stock encryption solution exactly works, but
> are you sure, that Luks does really satisfy your requirements?
> All files of all users will be encrypted with the same key when using
> Luks and when your filesystem is mounted, the webserver process or other
> processes may have access to all files, regardless of encryption.
> Ralf Ramsauer
> GPG: 0x8F10049B
> dm-crypt mailing list
> dm-crypt at saout.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt