Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Sean Rolinson (snowdogbigfoot.com)
Date: Tue Aug 07 2001 - 21:42:17 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Hash: SHA1


    Don't know if this is useful for anyone, but here are my findings
    with using vnconfig to create an encrypted filesystem.

    We were originally considering using cfs or tcfs as a means to
    encrypt a simple filesystem. However, after looking at cfs and tcfs,
    it's clear that both of these solutions are overkill for our needs.
    So we turned to vnconfig.

    There is a maximum size that you can use to create the svnd0
    filesystem. I couldn't find any documentation mentioning a size
    limit, and it wasn't until I tried to create a 4GB partition that I
    found the problem.

    The process for creating an encrypted filesystem with vnconfig is
    usually done with:

    dd if=/dev/zero of={filename} bs=1024 count=2097151
    vnconfig -cvk /dev/svnd0c test1.fs
    newfs /dev/snvd0c
    mkdir /crypt
    mount /dev/sndv0c /crypt

    The size listed above is the maximum and is approximately 2GB or more
    exactly 2097151k (or count=2097151). If you exceed this limit you'll
    get an error when using `vnconfig -cvk /dev/svnd0c {filename}`. The
    error will look something like this.

    server# vnconfig -cvk /dev/svnd0c test1.fs
    Encryption key:
    /dev/svnd0c: 0 bytes on test1.fs

    The "0 bytes" should reflect the number of bytes that was created
    using the "dd" command. In this case it would be "2147482624 bytes
    (1024 * 2097151). If the numbers don't match, you will have a
    problem running "newfs /dev/snvd0c". I forgot the exact error, but I
    think you get an "Inappropriate file format" or something along those
    lines. You might also see -xyz bytes when running vnconfig, which is
    also pretty bad. ;)

    Whatever you do, don't run `newfs /dev/vnd0c` (without the s). I
    tried this originally, and my box kernel panic'ed. This happened
    twice, with two different controllers and two different drives. I
    didn't run the trace or ps because I realized this was wrong. (Just
    thought I'd mention it).

    After doing the above and mounting the filesystem, I ran bonnie on
    the drive in clear text and on the encrypted filesystem. I was
    curious about the overhead of the encryption. My results are below:

    This was run on an 18GB U160 drive with an onboard adaptec controller
    (78xx? Intel STL2 Base Board).

    Clear Text Results:
                  -------Sequential Output-------- ---Sequential Input--
    - --Random--
                  -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
    - --Seeks---
    Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
    /sec %CPU
              100 27044 47.9 27744 18.5 2128 1.4 2639 5.8 2678 0.9
    244.2 0.8

    Encrypted Filesystem Results:
                  -------Sequential Output-------- ---Sequential Input--
    - --Random--
                  -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
    - --Seeks---
    Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
    /sec %CPU
              100 8324 84.3 8774 78.5 3811 51.9 7941 54.1 9769 48.8
    223.0 8.9

    NOTE: vnconfig does not ask for you to retype your
    password/encryption key, so you should be careful about entering it.
    I'd suggest immediately unconfiguring the device (vnconfig -u
    /dev/svnd0c) and reconfiguring it just to ensure your key is correct.
     If the password is not correct, you won't get an error until you try
    to mount /dev/svnd0c.

    That's about it... If anyone has any questions, feel free to drop me
    an email.



    Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

    -----END PGP SIGNATURE-----