All of lore.kernel.org
 help / color / mirror / Atom feed
* [dm-crypt] LUKS overhead?
@ 2014-09-09 16:11 Ryan Nix
  2014-09-09 17:32 ` Ralf Ramsauer
  2014-09-09 19:35 ` .. ink ..
  0 siblings, 2 replies; 4+ messages in thread
From: Ryan Nix @ 2014-09-09 16:11 UTC (permalink / raw)
  To: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Hello,

We recently started using ownCloud which has an encryption-at-rest option.
 However, their encryption scheme increases file size by 34%.  We need to
have our files encrypted at rest so I was thinking that maybe LUKS was the
better way to go.  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.

Thanks!

Ryan

[-- Attachment #2: Type: text/html, Size: 516 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dm-crypt] LUKS overhead?
  2014-09-09 16:11 [dm-crypt] LUKS overhead? Ryan Nix
@ 2014-09-09 17:32 ` Ralf Ramsauer
  2014-09-09 19:12   ` Ryan Nix
  2014-09-09 19:35 ` .. ink ..
  1 sibling, 1 reply; 4+ messages in thread
From: Ralf Ramsauer @ 2014-09-09 17:32 UTC (permalink / raw)
  To: dm-crypt

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
filesystems.
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.

Cheers
  Ralf

-- 
Ralf Ramsauer
GPG: 0x8F10049B

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dm-crypt] LUKS overhead?
  2014-09-09 17:32 ` Ralf Ramsauer
@ 2014-09-09 19:12   ` Ryan Nix
  0 siblings, 0 replies; 4+ messages in thread
From: Ryan Nix @ 2014-09-09 19:12 UTC (permalink / raw)
  To: Ralf Ramsauer; +Cc: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

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.

Cheers,

Ryan


On Tue, Sep 9, 2014 at 12:32 PM, Ralf Ramsauer <
ralf+dm@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
> filesystems.
> 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.
>
> Cheers
>   Ralf
>
> --
> Ralf Ramsauer
> GPG: 0x8F10049B
>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

[-- Attachment #2: Type: text/html, Size: 2715 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dm-crypt] LUKS overhead?
  2014-09-09 16:11 [dm-crypt] LUKS overhead? Ryan Nix
  2014-09-09 17:32 ` Ralf Ramsauer
@ 2014-09-09 19:35 ` .. ink ..
  1 sibling, 0 replies; 4+ messages in thread
From: .. ink .. @ 2014-09-09 19:35 UTC (permalink / raw)
  To: Ryan Nix; +Cc: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

On Tue, Sep 9, 2014 at 12:11 PM, Ryan Nix <ryan.nix@gmail.com> wrote:

> Hello,
>
> We recently started using ownCloud which has an encryption-at-rest option.
>  However, their encryption scheme increases file size by 34%.  We need to
> have our files encrypted at rest so I was thinking that maybe LUKS was the
> better way to go.  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.
>
>
How large are the files you are creating?

Most "enclosures" uses a header and the header will increase the overall
size of encrypted file.

LUKS for example uses a header that is 2MB.

If you want to encrypt individual files,why not go with gpg?,their header
will increase the file size by only 41 bytes.

[-- Attachment #2: Type: text/html, Size: 1242 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-09-09 19:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-09 16:11 [dm-crypt] LUKS overhead? Ryan Nix
2014-09-09 17:32 ` Ralf Ramsauer
2014-09-09 19:12   ` Ryan Nix
2014-09-09 19:35 ` .. ink ..

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.