I was on the point of making the same exact remark.
There's for sure a minor information leak (knowing the actual size of a sparse
file), but I fail to understand how an attacker could possibly take advantage
of that, in the (IMHO) highly unlikely event that she is able to steal your
backup tapes and make sense of what they contain.
Furthermore, the risk of having a full backup unencrypted seems to me slightly
worse than the possible compromise of a single file.
The best choice would probably be to allow encrypted backup of sparse files,
stating clearly that this could open a minor security issue and leaving to the
user the burden of balancing between his conflicting requirements.
Cheers,
Alberto
----- Original Message -----
From: "Adrian Reyer" <bacula-li...@lihas.de>
To: "Radosław Korzeniewski" <rados...@korzeniewski.net>
Cc: "Alberto Caporro" <a.capo...@consulthink.it>,
"Bacula-users@lists.sourceforge.net" <bacula-users@lists.sourceforge.net>
Sent: Sunday, April 7, 2013 11:48:42 PM
Subject: Re: [Bacula-users] Strange issue with backup size
On Sun, Apr 07, 2013 at 09:03:34PM +0200, Radosław Korzeniewski wrote:
> I think it is not possible to properly handle encrypted sparse data blocks
> without compromising security. The main data block size is 64kB long, so
> encrypted block should be more than 64kB long. Now, if we have a sparse
> block then its size is tens of bytes instead of 64kB, so encrypted block
> will be at the tens of bytes too not 64kB. So, if we have an encryption
> stream with a number of 64kB blocks (block boundary information is
> available on volume) and suddenly we will got a short block then for sure
> it will be a sparse block (I'm sure sparse block has its own stream
> number), then we can predict content. It is not good for security if we can
> predict original content. Think about it.
I am no mathematican but I don't really see how sparse blocks compromise
security in a real way. All an attacker knows is that a file that claims
to be 10G is only 10M, if this really compromises the encryption of the
actual content, I'd regard the used algorithm really broken.
Regards,
Adrian
--
LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
Fon: +49 (7 11) 78 28 50 90 - Fax: +49 (7 11) 78 28 50 91
Mail: li...@lihas.de - Web: http://lihas.de
Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
