Package: dar
Version: 2.3.2-1
Severity: important
Tags: security
I was looking through the crypto code in dar 2.3.2, and I found what I
think is a weakness in the Blowfish encryption code that results in
frequent initialization vector collisions.
Here is some background information from the dar(1) man page:
-#, --crypto-block <size>
to be able to randomly access data in an archive, it is not
encrypted globally but block by block. You can define the
encryption block size thanks to this argument which default to
10240 bytes. Note that syntax used for -s option is also available
here. Note also that crypto-block is stored as a 32 bits integer
thus value larger than 4GB will cause an error. Note last, that the
block size given here must be provided when reading this resulting
archive (through the -* or -# options). If it is not the correct
one, the archive will not be possible to decrypt, it is thus safe
to keep the default value (and not use at all the -# option).
The offending code is in dar-2.3.2/src/libdar/crypto.cpp (lines 178-194):
178: void blowfish::make_ivec(const infinint & ref, unsigned char ivec[8])
179: {
180: infinint upper = ref >> 32;
181: U_32 high = 0, low = 0;
182:
183: high = upper % (U_32)(0xFFFF); // for bytes (high weight)
184: low = ref % (U_32)(0xFFFF); // for bytes (lowest weight)
185:
186: ivec[0] = low % 8;
187: ivec[1] = (low >> 8) % 8;
188: ivec[2] = (low >> 16) % 8;
189: ivec[3] = (low >> 24) % 8;
190: ivec[4] = high % 8;
191: ivec[5] = (high >> 8) % 8;
192: ivec[6] = (high >> 16) % 8;
193: ivec[7] = (high >> 24) % 8;
194: }
Things to note:
- ivec is 8 x 8 = 64 bits
- block_num is assumed to be 64 bits
- Each byte of ivec is being assigned a value modulo 8 (i.e. 3 bits wide),
rather than a value modulo 256.
- The variables "high" and "low" are each assigned modulo 2**16-1 instead
of modulo 2**32 (or even modulo 2**16, which would be equivalent to
taking the lowest 4 bits of "upper" and "ref", respectively).
As far as I can tell, make_ivec is intended to serialize the 64-bit dar
block number ("ref") in a platform-independent way. If it did that, it
would still be violating the NIST SP 800-38A requirement that "for the CBC
and CFB modes, the IV for any particular execution of the encryption
process must be unpredictable". However, make_ivec actually *discards*
most of the bits of the block number, resulting in guaranteed IV collisions
at least every 8 'dar blocks' and a maximum effective IV length of slightly
less than 12 bits.
Using the default block size of 10240 bytes (as recommended by the dar
manual page), this translates into an IV collision every 81920 bytes, and
an IV space of less than 4096 possible values.
The result is a severely weakened implementation of Blowfish-CBC.
What make_ivec should probably do is (as recommended by NIST SP 800-38A,
Appendix C) to generate the initialization vectors encrypt the 64-bit block
number using blowfish and the same key that is used to encrypt the data
blocks.
NIST SP 800-38A can be found at:
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dar depends on:
ii libattr1 1:2.4.32-1.1 Extended attribute shared library
ii libbz2-1.0 1.0.3-6 high-quality block-sorting file co
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libdar64-4 2.3.2-1 Disk ARchive: Shared library
ii libgcc1 1:4.1.1-21 GCC support library
ii libssl0.9.8 0.9.8e-4 SSL shared libraries
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
ii zlib1g 1:1.2.3-13 compression library - runtime
dar recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
