-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
What exactly is the status of the loopback device in 2.2.20 with regards
to relative block support? Is it *really* supported?
The reason I am asking is that I've run into trouble retrieving data off
of a loopback file after I switched to a new machine. I was using loopback
in combination with the kerneli patch to mount an encrypted filesystem
and backup my data to it for safe transport to another machine. The
decryption seems to be largely successful, since I am able to see most of
the data when peering at the decrypted file using a hexeditor.
However, there is very pervasive corruption going on in the decrypted file
and I am unable to even mount it. The first problem was that one of the
groups had completely bogus values for its block and inode bitmaps. E.g.
instead of 131073 (0x20001), the block bitmap for group 16 read 675963312.
This was fairly straightforward to sort out, but unfortunately it was only
one of many such "noise". For many inodes, the first couple of bytes are
corrupted, making some of the directories' inode types invalid and
preventing me from reading them. Another example was my secring.gpg, the
first block for which I found by searching through the image file. While
it was obvious that some of the data in there did, indeed, belong in my
keyring, the first two bytes didn't contain the magic 95 01 but something
random instead. Dumping that block to a file and changing the first two
bytes didn't make GPG too happy either (surprise, surprise...)
This has happened to 3 different backups, on different dates, and in
all cases the corruption follows the same pattern. Unfortunately I only
verified that I was able to read these files back on the original machine,
where everything worked fine. I now find myself in the unenviable
position of having unreadable backups, no originals, and only a limited
understanding of what is wrong.
As I said, I had compiled the kernel with encrypted loopback enabled. I
also specified CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK since I expected to have
to move the backup files around. Now that I am in the process of trying
to understand the loopback code - and, to a large extent, the ext2 code as
well since I'm a complete novice to that - a comment in loop.c attracted
my attention. It said that the block number passed as IV to lower level
transfer functions is still the underlying device's block number instead
of the block within the loopback filesystem. I remember a discussion on
linux-kernel a long time ago
[http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0923.html]
where it was proposed to pass relative block numbers along everywhere,
leaving it up to the encryption modules to calculate the absolute block
numbers where needed. This discussion centered around the 2.3 kernel,
though, if I remember correctly, and I used the 2.2 kernel.
My old machine was a Pentium II, and the new one is a Pentium III
Mobile. The kernel version was the same on both, since I installed the
kernel packages I compiled on the old machine as soon as I got the new
one. The files were encrypted using Serpent encryption. I burned them
onto CD before losing the old machine, then copied them from CD onto
my new machine.
I first posted on the linux-crypto list to see if somebody might
understand what's my problem, but now I believe it isn't really something
to do with encryption. If, for any reason, it would fail to decrypt
properly, then the result would be utter randomness wouldn't it? I wish I
had more of a clue what could be wrong...
If someone knows what might be wrong I'd very much appreciate any help,
suggestions or even (dare I hope?) outright solutions. I can provide more
data if I know what is needed, so please do ask.
Thanks in advance,
mailerror
p.s. I'd appreciate it if you CC'd me on any replies. I do read the list
but am not subscribed to it (yet).
Hush provide the worlds most secure, easy to use online applications - which solution is right for you?
HushMail Secure Email http://www.hushmail.com/
HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/
Hush Business - security for your Business http://www.hush.com/
Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com
wl4EARECAB4FAjx28ToXHG1haWxlcnJvckBodXNobWFpbC5jb20ACgkQb539PwJB5JMN
MQCdHHlfwYfqjGNxF1GOXI6BFKURWIgAnA2wFCZp+UkBSw4htDeVGKHLHMQ3
=6wkj
-----END PGP SIGNATURE-----
[email protected] wrote:
> What exactly is the status of the loopback device in 2.2.20 with regards
> to relative block support? Is it *really* supported?
>
> The reason I am asking is that I've run into trouble retrieving data off
> of a loopback file after I switched to a new machine. I was using loopback
> in combination with the kerneli patch to mount an encrypted filesystem
> and backup my data to it for safe transport to another machine. The
> decryption seems to be largely successful, since I am able to see most of
> the data when peering at the decrypted file using a hexeditor.
Kerneli patches use block size dependant IV computation (also called "time
bomb" IV). Shit hits the fan when you move files to a device with different
block size. Search linux-crypto archives for more information.
Regards,
Jari Ruusu <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 23 Feb 2002 21:47:56 +0200, Jari Ruusu <[email protected]> wrote:
>[email protected] wrote:
>> What exactly is the status of the loopback device in 2.2.20 with regards
>> to relative block support? Is it *really* supported?
>>
>Kerneli patches use block size dependant IV computation (also called "time
>bomb" IV). Shit hits the fan when you move files to a device with different
>block size. Search linux-crypto archives for more information.
Aha. So if I moved the loopback file onto a partition with the same blocksize
again, it would all be fine?
mailerror
Hush provide the worlds most secure, easy to use online applications - which solution is right for you?
HushMail Secure Email http://www.hushmail.com/
HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/
Hush Business - security for your Business http://www.hush.com/
Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com
wl4EARECAB4FAjx6YkwXHG1haWxlcnJvckBodXNobWFpbC5jb20ACgkQb539PwJB5JOc
YACdHtDNGubq9SaNZYV/KaInmQMpJf8AoJEIc/weLqdnL3HhhyTpRRTJgqV9
=iQaH
-----END PGP SIGNATURE-----
[email protected] wrote:
> On Sat, 23 Feb 2002 21:47:56 +0200, Jari Ruusu <[email protected]> wrote:
> >Kerneli patches use block size dependant IV computation (also called "time
> >bomb" IV). Shit hits the fan when you move files to a device with different
> >block size. Search linux-crypto archives for more information.
>
> Aha. So if I moved the loopback file onto a partition with the same blocksize
> again, it would all be fine?
If you can move original (unmodified) loop file to same block size, same
kernel version, then yes. If you mounted it rw, then your "time bomb"
exploded on your face.
Regards,
Jari Ruusu <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 25 Feb 2002 20:41:25 +0200, Jari Ruusu <[email protected]> wrote:
>[email protected] wrote:
>> On Sat, 23 Feb 2002 21:47:56 +0200, Jari Ruusu <[email protected]> wrote:
>> >Kerneli patches use block size dependant IV computation (also called "time
>> >bomb" IV). Shit hits the fan when you move files to a device with different
>> >block size. Search linux-crypto archives for more information.
>>
>> Aha. So if I moved the loopback file onto a partition with the same blocksize
>> again, it would all be fine?
>
>If you can move original (unmodified) loop file to same block size, same
>kernel version, then yes. If you mounted it rw, then your "time bomb"
>exploded on your face.
>
Okay, my files are fine then, since the files were burned on cd right after I
created them.
Is this still a problem with the 2.4 loop device? In your patch for 2.4.16
I noticed that the IV calculation is independent from the underlying block
size. That alone would be enough to make me switch over from 2.2 ;-)
thanks a lot..
mailerror
Hush provide the worlds most secure, easy to use online applications - which solution is right for you?
HushMail Secure Email http://www.hushmail.com/
HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/
Hush Business - security for your Business http://www.hush.com/
Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com
wl4EARECAB4FAjx6lMEXHG1haWxlcnJvckBodXNobWFpbC5jb20ACgkQb539PwJB5JNC
zQCdFCCDIQTekRvch+NwN2Z2mU4SOmIAoK5Z9j5SMGaxOLPUPnWw9N6zxR/J
=BmUy
-----END PGP SIGNATURE-----
[email protected] wrote:
> On Mon, 25 Feb 2002 20:41:25 +0200, Jari Ruusu <[email protected]> wrote:
> >If you can move original (unmodified) loop file to same block size, same
> >kernel version, then yes. If you mounted it rw, then your "time bomb"
> >exploded on your face.
> >
>
> Okay, my files are fine then, since the files were burned on cd right after I
> created them.
>
> Is this still a problem with the 2.4 loop device? In your patch for 2.4.16
> I noticed that the IV calculation is independent from the underlying block
> size. That alone would be enough to make me switch over from 2.2 ;-)
Recent versions of cryptoapi do 512 byte IV as do all versions of loop-AES
(maintained by me, http://loop-aes.sourceforge.net/). If you want to keep
using 2.2 kernels or want to use distro vendor kernels, loop-AES is better
choice as it works with all kernels and has more up to date loop fixes than
cryptoapi.
Regards,
Jari Ruusu <[email protected]>