Hello,
Could you please answer the following question:
Suppose we have a crypto filesystem on a raid1 array of 2 devices. What will
the kernel cache of fileystem data contain - encrypted data or not? Will is
be 2 copies of the same data in the cache or not?
Is there any way to force kernel to cache the same file data only once, and
keep it unencrypted (in cache)?
Thanks in advance.
--
Best regards,
-Vlad
On Sun, Mar 02, 2003 at 02:56:34PM +0400, Vlad Harchev wrote:
> Hello,
>
> Could you please answer the following question:
>
> Suppose we have a crypto filesystem on a raid1 array of 2 devices. What will
> the kernel cache of fileystem data contain - encrypted data or not? Will is
> be 2 copies of the same data in the cache or not?
Sorry for confusion - of course I meant linux software raid here..
> Is there any way to force kernel to cache the same file data only once, and
> keep it unencrypted (in cache)?
>
--
Best regards,
-Vlad
On Monday March 3, [email protected] wrote:
> On Sun, Mar 02, 2003 at 02:56:34PM +0400, Vlad Harchev wrote:
> > Hello,
> >
> > Could you please answer the following question:
> >
> > Suppose we have a crypto filesystem on a raid1 array of 2 devices. What will
> > the kernel cache of fileystem data contain - encrypted data or not? Will is
> > be 2 copies of the same data in the cache or not?
>
> Sorry for confusion - of course I meant linux software raid here..
With raid1 has no effect on caching. Exactly the same data is cached
with raid1 as with as plain SCSI or IDE drive.
Raid5 is different. It has an extra cache of some of the data that
has been written-to or read-from the devices.
>
> > Is there any way to force kernel to cache the same file data only once, and
> > keep it unencrypted (in cache)?
> >
I suspect that depends of the details of the implementation of you
"crypto filesystem".
NeilBrown
On Tue, Mar 04, 2003 at 08:50:46AM +1100, Neil Brown wrote:
> On Monday March 3, [email protected] wrote:
> > On Sun, Mar 02, 2003 at 02:56:34PM +0400, Vlad Harchev wrote:
> > > Hello,
> > >
> > > Could you please answer the following question:
> > >
> > > Suppose we have a crypto filesystem on a raid1 array of 2 devices. What will
> > > the kernel cache of fileystem data contain - encrypted data or not? Will is
> > > be 2 copies of the same data in the cache or not?
> >
> > Sorry for confusion - of course I meant linux software raid here..
>
> With raid1 has no effect on caching. Exactly the same data is cached
> with raid1 as with as plain SCSI or IDE drive.
The question I asked is - will under the active usage there be exactly one
copy of a file's data, or there will be N (where N is number of disks in raid1
array) copies in the cache? I.e. how optimal caching is performed?
> Raid5 is different. It has an extra cache of some of the data that
> has been written-to or read-from the devices.
OK, thank you for pointing this.
>
> >
> > > Is there any way to force kernel to cache the same file data only once, and
> > > keep it unencrypted (in cache)?
> > >
>
> I suspect that depends of the details of the implementation of you
> "crypto filesystem".
Sorry for confusion - I meant loopback-based crypto filesystem - e.g. loop-aes
based (loop-aes.sourceforge.net) or CryptoAPI-based (http://www.kerneli.org) - both
are loopback-based filesystem (one has to call losetup(8) to point out chipher,
a password..) I'm getting an impression that the kernel cache will contain
encrypted data in case loopback-based crypto filesystems are used just
observing performance..
Thank you for the anwser!
--
Best regards,
-Vlad
On Tue, 4 March 2003 13:30:20 +0400, Vlad Harchev wrote:
>
> Sorry for confusion - I meant loopback-based crypto filesystem - e.g. loop-aes
> based (loop-aes.sourceforge.net) or CryptoAPI-based (http://www.kerneli.org) - both
> are loopback-based filesystem (one has to call losetup(8) to point out chipher,
> a password..)
Loopback with encryption is not the same as a crypto filesystem.
Loopback encryption works transparently with any (non-)crypto fs.
A potential attacker can use this to look for the ext2 superblock,
which gives him the same data both encrypted an unencrypted. A real
cryptofs would go through great pains to take such advantages away.
J?rn
--
Invincibility is in oneself, vulnerability is in the opponent.
-- Sun Tzu
On Tue, Mar 04, 2003 at 10:20:31AM +0100, J?rn Engel wrote:
> On Tue, 4 March 2003 13:30:20 +0400, Vlad Harchev wrote:
> >
> > Sorry for confusion - I meant loopback-based crypto filesystem - e.g. loop-aes
> > based (loop-aes.sourceforge.net) or CryptoAPI-based (http://www.kerneli.org) - both
> > are loopback-based filesystem (one has to call losetup(8) to point out chipher,
> > a password..)
>
> Loopback with encryption is not the same as a crypto filesystem.
> Loopback encryption works transparently with any (non-)crypto fs.
Yes, you are right.
> A potential attacker can use this to look for the ext2 superblock,
> which gives him the same data both encrypted an unencrypted. A real
I've got an impression that in case of loopback with encryption the
superblock will also be encrypted.
If one forgets known cleartext attacks, one can place the filesystem at
some offset.
> cryptofs would go through great pains to take such advantages away.
>
--
Best regards,
-Vlad
Vlad Harchev wrote:
>>A potential attacker can use this to look for the ext2 superblock,
>>which gives him the same data both encrypted an unencrypted. A real
>
>
> I've got an impression that in case of loopback with encryption the
> superblock will also be encrypted.
> If one forgets known cleartext attacks, one can place the filesystem at
> some offset.
Yes it would be encrypted. Unfortunately it is predictable data and as
such it is much easier to crack. Better set that offset at a location
computed from the encryption key.
On a side note I find it interesting that many people sugest compressing
a file before encrypting it. Take a look at the first few bytes of
every compressed file. Unless your going to get rid of that header...
>>cryptofs would go through great pains to take such advantages away.
- Bryan