too much encryption - Security

This is a discussion on too much encryption - Security ; I've been experimenting with improving security on my little home network. I had no trouble setting up a file server using LUKS to encrypt several physical volumes and LVM to create logical volumes over them so that all the data ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: too much encryption

  1. too much encryption

    I've been experimenting with improving security on my little home network.

    I had no trouble setting up a file server using LUKS to encrypt several
    physical volumes and LVM to create logical volumes over them so that
    all the data on the file server is encrypted. I manually activate the
    physical volumes after boot using a key stored on a USB key, so now I'm
    comfortable that if my server gets stolen out of the garage or I have
    to RMA a hard drive, there's very little danger that any of my personal
    information will be exposed.

    The problem, now, is CPU load on the file server. I have two sets of
    encrypted disks in the the server, and use rsync to back up from one to
    the other. Backups take about three times as long as they did before I
    encrypted the disks, and the CPU is the bottleneck. Even heavy network
    activity, like when I back up a laptop to the file server, keeps the
    AMD Athlon 1900+ CPU pegged, although it still seems to be able to keep
    up with the 100/base-T speeds.

    In thinking about the problem I realized that some data is repeatedly
    encrypted and decrypted through the process. For example, my main
    laptop is a Mac, so my home directory is encrypted inside an Apple disk
    image file on the laptop. So when I backup that laptop the data has to
    be decrypted on the laptop, then encrypted for transfer over the
    wireless network. Then, on the file server, it gets decrypted from the
    network transfer, then re-encrypted to be writen to the disk. Then,
    when I run the file-server's backup, the data gets decrypted once more
    and then re-encrypted to be written to the backup disks.

    Obviously, what I really need is just a network filesystem that never
    tries to decrypt the stuff it's storing. Why would the file server
    itself ever need to read the data, anyway? But I've spent a couple of
    days digging, and haven't come up with anything like that.

    Before I started this experimenting I was mounting encrypted Apple disk
    partitions from the file server. That means that all the
    encryption/decryption was being done by the client computer, and
    ensured that the unencrypted data was never stored on the fileserver.
    However, I found out the hard way that the disk image files are very
    easily corrupted, and any problem with the image file means you lose
    everything in that image.

    So, any suggestions on network filesystems that don't try to decrypt
    the data on the file server?

    There's not any way to copy data from one encrypted filesystem to
    another without decrypting and re-encrypting it, is there?

    Any other ideas on how I can make the clients to the heavy lifting, and
    let the file server just store the data?


  2. Re: too much encryption

    Mr. Paranoid (06-10-18 16:05:26):

    > So, any suggestions on network filesystems that don't try to decrypt
    > the data on the file server?
    >
    > There's not any way to copy data from one encrypted filesystem to
    > another without decrypting and re-encrypting it, is there?
    >
    > Any other ideas on how I can make the clients to the heavy lifting,
    > and let the file server just store the data?


    Yes, think of a totally different concept. Give every user an own disk
    partition (which could be simply a file on the actual physical storage).
    There is a way to mount block devices remotely, which is then called a
    "network block device". Enable it in your kernel configuration. You
    will also need the tools to set it up, but your distribution usually
    supplies them.

    What is different is that all data crossing the network will be
    unencrypted -- from the low-level view. Actually the encryption is done
    on the client machine, which eliminates the need to use an encrypted
    protocol for the transfer. No single unencrypted byte ever leaves the
    client machine. This also simplifies the backup process: just copy over
    the image file, which is encrypted anyway.

    I haven't used NBDs myself yet, but I've seen them in action. It's
    easy. For the client it's like mounting them locally.

    By the way, which cipher implementation are you using? I would
    recommend dm-crypt or Loop-AES for performance. Just don't use plain
    cryptoloop, because it's not only slow, but even less secure; because it
    is essentially an ECB-mode cipher, it reveals some information about the
    data saved on the encrypted disk. For today's filesystems, where there
    is a lot of redundant data, this may impose a security risk.

    The cipher itself is important, too. I assume that you have read some
    articles about the various ciphers, so you most likely use AES. That's
    totally fine, but AES is rather slow, compared to some older ciphers.
    If performance is important, use Blowfish instead. As for AES, no
    practically exploitable security problems have been found in Blowfish so
    far.


    Regards,
    E.S.

  3. Re: too much encryption

    Ertugrul Soeylemez wrote:
    > Mr. Paranoid (06-10-18 16:05:26):
    >
    >> So, any suggestions on network filesystems that don't try to decrypt
    >> the data on the file server?


    Have you looked at EncFS? Its a userspace module. Using this will give
    access to various ciphers when using openssl >= 0.9.7.

    http://arg0.net/users/vgough/encfs.html

    > The cipher itself is important, too. I assume that you have read some
    > articles about the various ciphers, so you most likely use AES. That's
    > totally fine, but AES is rather slow, compared to some older ciphers.
    > If performance is important, use Blowfish instead. As for AES, no
    > practically exploitable security problems have been found in Blowfish so
    > far.


    Agreed. Blowfish is very fast and reliable. Its one of the few
    remaining ciphers that has not been broken even in the lab...besides,
    anything from the BSD community is almost guaranteed to be safe :P.

    --
    irish

  4. Re: too much encryption


    > > The cipher itself is important, too. I assume that you have read some
    > > articles about the various ciphers, so you most likely use AES. That's
    > > totally fine, but AES is rather slow, compared to some older ciphers.
    > > If performance is important, use Blowfish instead. As for AES, no
    > > practically exploitable security problems have been found in Blowfish so
    > > far.

    >
    > Agreed. Blowfish is very fast and reliable. Its one of the few
    > remaining ciphers that has not been broken even in the lab...besides,
    > anything from the BSD community is almost guaranteed to be safe :P.
    >


    I wouldn't exactly agree with everything in these statements.

    Looking at Wei Dai's benchmarks (Crypto++ library) for Blowfish vs AES,
    you see Blowfish gets roughly 64 MB/Sec while AES (Rijndael) gets 61
    MB/Sec. This agrees with Brian Gladman's benchmark of AES, about 69
    MB/Sec. So for performance, I don't think it really matters.

    Secondly, Blowfish has a problem that AES doesn't in that Blowfish uses
    a 64-bit block size. AES uses a 128-bit block size. I'm going to
    presume whatever software you are using is using AES in CBC mode, as
    that is what most people do.

    CBC mode has a property that after about 2^{n/2} blocks, where n is the
    block size, you begin to leak information about the plaintext. That is,
    after
    64 * 2^{64/2} bits = 64 * 2^32 bits = 32 GB, Blowfish is going to start
    leaking information.

    With AES however, you wouldn't see this leak until 128 * 2^64 bits =
    274,877,906,944 GB

    Blowfish is a great algorithm, but I think it's time is starting to
    pass.

    -Matt


  5. Re: too much encryption

    mfanto@gmail.com (06-10-19 08:45:40):

    > > > The cipher itself is important, too. I assume that you have read
    > > > some articles about the various ciphers, so you most likely use
    > > > AES. That's totally fine, but AES is rather slow, compared to
    > > > some older ciphers. If performance is important, use Blowfish
    > > > instead. As for AES, no practically exploitable security problems
    > > > have been found in Blowfish so far.

    > >
    > > Agreed. Blowfish is very fast and reliable. Its one of the few
    > > remaining ciphers that has not been broken even in the
    > > lab...besides, anything from the BSD community is almost guaranteed
    > > to be safe :P.


    Actually Blowfish has been invented by Bruce Schneier. He is not
    involved in BSD, as far as I know. I might be wrong, though.


    > I wouldn't exactly agree with everything in these statements.
    >
    > Looking at Wei Dai's benchmarks (Crypto++ library) for Blowfish vs
    > AES, you see Blowfish gets roughly 64 MB/Sec while AES (Rijndael) gets
    > 61 MB/Sec. This agrees with Brian Gladman's benchmark of AES, about 69
    > MB/Sec. So for performance, I don't think it really matters.


    That really depends on the implementation. If both implementations were
    equally well optimized, then Blowfish would outperform AES noticably.
    However, I use AES for disk encryption, too, but I prefer Blowfish for
    my swap space.


    > Secondly, Blowfish has a problem that AES doesn't in that Blowfish
    > uses a 64-bit block size. AES uses a 128-bit block size. I'm going to
    > presume whatever software you are using is using AES in CBC mode, as
    > that is what most people do.
    >
    > CBC mode has a property that after about 2^{n/2} blocks, where n is
    > the block size, you begin to leak information about the
    > plaintext. That is, after 64 * 2^{64/2} bits = 64 * 2^32 bits = 32 GB,
    > Blowfish is going to start leaking information.
    >
    > With AES however, you wouldn't see this leak until 128 * 2^64 bits =
    > 274,877,906,944 GB


    Implementations are free to apply the IV to either the clear-text block
    or to the key. Doing the latter would invalidate that statement, as
    then the CBC cycle depends on the key size instead of the block size.


    > Blowfish is a great algorithm, but I think it's time is starting to
    > pass.


    That may be true, but it's still a fine algorithm for things like swap,
    at least for now. What I like about Blowfish is that only a single
    noticable flaw has been found so far. There are a number of insecure
    keys, but anyway, the probability to get such a bad key is impracticably
    low.


    Regards,
    E.S.

  6. Re: too much encryption

    Ertugrul Soeylemez wrote:
    > > Looking at Wei Dai's benchmarks (Crypto++ library) for Blowfish vs
    > > AES, you see Blowfish gets roughly 64 MB/Sec while AES (Rijndael) gets
    > > 61 MB/Sec. This agrees with Brian Gladman's benchmark of AES, about 69
    > > MB/Sec. So for performance, I don't think it really matters.

    >
    > That really depends on the implementation. If both implementations were
    > equally well optimized, then Blowfish would outperform AES noticably.
    > However, I use AES for disk encryption, too, but I prefer Blowfish for
    > my swap space.


    That was my point though. Unless I am misunderstanding Wei Dai's
    benchmarks, it shows a similar performance of both. I've seen other
    benchmarks that agree. Of course, there are some issues with timing
    attacks, which means you can't use fully optimized code of both. But I
    think in the general case, you are not going to notice any difference
    in speed. AES was picked because of it's performance. Unless you are a
    seriously loaded webserver doing massive TLS connections, I don't see
    any advantage to using Blowfish.


    > > Secondly, Blowfish has a problem that AES doesn't in that Blowfish
    > > uses a 64-bit block size. AES uses a 128-bit block size. I'm going to
    > > presume whatever software you are using is using AES in CBC mode, as
    > > that is what most people do.
    > >
    > > CBC mode has a property that after about 2^{n/2} blocks, where n is
    > > the block size, you begin to leak information about the
    > > plaintext. That is, after 64 * 2^{64/2} bits = 64 * 2^32 bits = 32 GB,
    > > Blowfish is going to start leaking information.
    > >
    > > With AES however, you wouldn't see this leak until 128 * 2^64 bits =
    > > 274,877,906,944 GB

    >
    > Implementations are free to apply the IV to either the clear-text block
    > or to the key. Doing the latter would invalidate that statement, as
    > then the CBC cycle depends on the key size instead of the block size.


    I assume when you say apply to the key, you mean you do something like
    IV xor KEY and then
    previous_CT xor KEY for each block.

    CBC isn't defined in terms of applying the IV to the key. CBC is
    defined as applying the previous ciphertext block to the next plaintext
    block. I've never seen any implementation or standard in which the IV
    is applied to the key, but if you have references, I'd love to see
    them. If you start chaining with keys, you run the risk of breaking the
    benefits of CBC. I haven't fully thought about it, but at the very
    least, error propogation is going to be different.

    During the decryption phase, with CBC (the real CBC), a single bit
    error in the ciphertext (perhaps the bit error is due to the storage
    medium) will cause complete corruption of that block, and the
    corresponding bit in the next plaintext block to be inverted. Using a
    checksum, you can then "fix" that next plaintext block, so you end up
    with a single bit error causing a loss of a block.

    In your scheme however, a single bit error in the ciphertext would
    cause two full blocks to be completely corrupted. The ciphertext block
    with an error would decrypt to garbage. That errored block would be
    XORed with the key in the next block, producing basically a different
    key, which would then cause the next plaintext block to be destroyed
    (as the next ciphertext block is being decrypted under the wrong key).

    There are probably some security concerns as well.

    But I digress.

    >
    > > Blowfish is a great algorithm, but I think it's time is starting to
    > > pass.

    >
    > That may be true, but it's still a fine algorithm for things like swap,
    > at least for now. What I like about Blowfish is that only a single
    > noticable flaw has been found so far. There are a number of insecure
    > keys, but anyway, the probability to get such a bad key is impracticably
    > low.
    >


    I agree that Blowfish is fine for a lot of things, but I think with the
    massive amounts of storage people are beginning to aquire, and the
    availability of things like AES, means implementations should be moving
    away from 64-bit block sizes. For swap space though, it's probably less
    of a concern, since I really hope you are not swapping that much to
    disk that you will be hitting a 32GB limit. The other advantage to AES
    is it is the standard.

    But what flaw are you refering to? The best attack is a 4 round 2nd
    order differential. The weak keys don't even really apply, since it is
    a small class of them. The weak keys allow 14 rounds of Blowfish to be
    distinguished from pseudorandom permutation. Blowfish is defined with
    16 rounds, so the weak keys shouldn't be a problem for anyone.

    -Matt


  7. Re: too much encryption

    "Matthew Fanto" (06-10-20 00:12:23):

    > > > Secondly, Blowfish has a problem that AES doesn't in that Blowfish
    > > > uses a 64-bit block size. AES uses a 128-bit block size. I'm going
    > > > to presume whatever software you are using is using AES in CBC
    > > > mode, as that is what most people do.
    > > >
    > > > CBC mode has a property that after about 2^{n/2} blocks, where n
    > > > is the block size, you begin to leak information about the
    > > > plaintext. That is, after 64 * 2^{64/2} bits = 64 * 2^32 bits = 32
    > > > GB, Blowfish is going to start leaking information.
    > > >
    > > > With AES however, you wouldn't see this leak until 128 * 2^64 bits
    > > > = 274,877,906,944 GB

    > >
    > > Implementations are free to apply the IV to either the clear-text
    > > block or to the key. Doing the latter would invalidate that
    > > statement, as then the CBC cycle depends on the key size instead of
    > > the block size.

    >
    > I assume when you say apply to the key, you mean you do something like
    > IV xor KEY and then previous_CT xor KEY for each block.
    >
    > CBC isn't defined in terms of applying the IV to the key. CBC is
    > defined as applying the previous ciphertext block to the next
    > plaintext block. I've never seen any implementation or standard in
    > which the IV is applied to the key, but if you have references, I'd
    > love to see them. If you start chaining with keys, you run the risk of
    > breaking the benefits of CBC. I haven't fully thought about it, but at
    > the very least, error propogation is going to be different.
    >
    > During the decryption phase, with CBC (the real CBC), a single bit
    > error in the ciphertext (perhaps the bit error is due to the storage
    > medium) will cause complete corruption of that block, and the
    > corresponding bit in the next plaintext block to be inverted. Using a
    > checksum, you can then "fix" that next plaintext block, so you end up
    > with a single bit error causing a loss of a block.
    >
    > In your scheme however, a single bit error in the ciphertext would
    > cause two full blocks to be completely corrupted. The ciphertext block
    > with an error would decrypt to garbage. That errored block would be
    > XORed with the key in the next block, producing basically a different
    > key, which would then cause the next plaintext block to be destroyed
    > (as the next ciphertext block is being decrypted under the wrong key).


    Uhm. I have confused CBC with CTR. The reason is, we were talking
    about disk encryption, so CBC mode doesn't make much sense anyway.


    Regards,
    E.S.

  8. Re: too much encryption

    >
    > Uhm. I have confused CBC with CTR. The reason is, we were talking
    > about disk encryption, so CBC mode doesn't make much sense anyway.
    >


    A lot of disk encryption software uses CBC mode. LRW is a beter mode
    for disk encryption anyway. CTR has it's own set of problems for
    encrypting sectors.

    http://en.wikipedia.org/wiki/Disk_encryption


  9. Re: too much encryption

    "Matthew Fanto" (06-10-20 18:25:21):

    > > Uhm. I have confused CBC with CTR. The reason is, we were talking
    > > about disk encryption, so CBC mode doesn't make much sense anyway.

    >
    > A lot of disk encryption software uses CBC mode. LRW is a beter mode
    > for disk encryption anyway.


    You cannot use CBC mode efficiently for live (!) filesystem encryption,
    as you would have to decrypt from the first block up to the actual block
    to be read, unless you restart CBC mode at certain blocks. It's good,
    however, for static encryptions.


    > CTR has it's own set of problems for encrypting sectors.


    Could you name some of them? Where i is the block number (not
    necessarily starting at 0 or 1), my idea of an encryption from message
    m_i to ciphertext c_i in CTR mode is one of:

    c_i = E_k(m_i + hash(i))
    c_i = E_(k + hash(i))(m_i)

    Here E_k is the encryption function using key k, and hash() is a secure
    hash function, which produces a hash of the size of a block (first
    scheme), or the size of the key (second scheme). Unless you can find a
    relation between hash(i) and hash(i + 1), this scheme appears secure to
    me.


    Regards,
    E.S.

  10. Re: too much encryption


    Ertugrul Soeylemez wrote:


    > You cannot use CBC mode efficiently for live (!) filesystem encryption,
    > as you would have to decrypt from the first block up to the actual block
    > to be read, unless you restart CBC mode at certain blocks. It's good,
    > however, for static encryptions.


    One way to do it is each sector gets it's own IV for encryption. That
    way when a sector is read, you only need to decrypt that sector. The
    problem is getting an IV for each sector. Using a random IV is hard,
    because that would require a ton of calls to /dev/{u}random. Also,
    storing a 128-bit IV for each sector could be a problem, as it would
    take up more space and be hard to do. Some software will use the sector
    number as the IV, but since this is predictable, it's vulnerable to a
    watermarking attack. Since we define encryption as c_i = E(Sector ^
    m_i), the attacker can use specially crafted files, m_i, and have some
    assurance that his malicious file was written to disk.

    >
    > > CTR has it's own set of problems for encrypting sectors.

    >
    > Could you name some of them?


    Sure. This attack should work if you use either the same IV for the
    entire volume, or a per-sector IV (i.e. each sector get's its own IV).

    CTR has a keystream generated like this: k_i = E_K(IV || counter)
    and encryption is defined as
    c_i = k_i ^ m_i

    Lets say I read your encrypted volume and find all ciphertext. Now
    suppose later, I get your volume again and look at the ciphertext
    again. Any file that has changed, I can recover some information.

    Say sector X has changed. Originally you had
    c_i_orig = k_i ^ m_i_orig

    A few weeks later, you replace the file, and now you have
    c_i_new = k_i ^ m_i_new

    I as the attacker know c_i_orig and c_i_new (i just read the encrypted
    drive).

    If I take the XOR of these two, I get
    c_i_orig ^ c_i_new = k_i ^ m_i_orig ^ k_i ^ m_i_new

    and since the k_i cancells due to XOR.

    c_i_orig ^ c_i_new = m_i_orig ^ m_i_new

    So the XOR of the ciphertext is the XOR of the original file. Since
    English has a lot of redundancy, I can use some statistical tests and
    recover parts of the two files.


    > Where i is the block number (not
    > necessarily starting at 0 or 1), my idea of an encryption from message
    > m_i to ciphertext c_i in CTR mode is one of:
    >
    > c_i = E_k(m_i + hash(i))
    > c_i = E_(k + hash(i))(m_i)
    >
    > Here E_k is the encryption function using key k, and hash() is a secure
    > hash function, which produces a hash of the size of a block (first
    > scheme), or the size of the key (second scheme). Unless you can find a
    > relation between hash(i) and hash(i + 1), this scheme appears secure to
    > me.


    I see a problem with it, but I don't have time tonight to write
    something up. I think you can still use a watermarking attack on it.
    I'll leave it as an exercise to the reader . Or I can write it up
    later if you still want.

    You should check out LRW mode, it's kinda neat and solves these
    problems.

    -Matt


  11. Re: too much encryption

    "Matthew Fanto" (06-10-22 14:21:04):

    > > > CTR has it's own set of problems for encrypting sectors.

    > >
    > > Could you name some of them?

    >
    > Sure. This attack should work if you use either the same IV for the
    > entire volume, or a per-sector IV (i.e. each sector get's its own IV).
    >
    > CTR has a keystream generated like this: k_i = E_K(IV || counter) and
    > encryption is defined as c_i = k_i ^ m_i
    >
    > [...]


    Oh well, then my idea isn't actually CTR, but rather a variation of CBC.


    > > Where i is the block number (not necessarily starting at 0 or 1), my
    > > idea of an encryption from message m_i to ciphertext c_i in CTR mode
    > > is one of:
    > >
    > > c_i = E_k(m_i + hash(i))
    > > c_i = E_(k + hash(i))(m_i)
    > >
    > > Here E_k is the encryption function using key k, and hash() is a
    > > secure hash function, which produces a hash of the size of a block
    > > (first scheme), or the size of the key (second scheme). Unless you
    > > can find a relation between hash(i) and hash(i + 1), this scheme
    > > appears secure to me.

    >
    > I see a problem with it, but I don't have time tonight to write
    > something up. I think you can still use a watermarking attack on it.
    > I'll leave it as an exercise to the reader . Or I can write it up
    > later if you still want.
    >
    > You should check out LRW mode, it's kinda neat and solves these
    > problems.


    Yes, the LRW mode looks good. But I can improve my scheme to be
    watermarking-proof:

    c_i = E_(k + M_k(i))(m_i)

    However, LRW is faster, so I'd just stick with that. =)


    Regards,
    E.S.

  12. Re: too much encryption

    Ertugrul Soeylemez (06-10-27 04:12:44):

    > Yes, the LRW mode looks good. But I can improve my scheme to be
    > watermarking-proof:
    >
    > c_i = E_(k + M_k(i))(m_i)


    I forgot to mention that M_k is a secure MAC function using key k.

  13. Re: too much encryption

    On 2006-10-19 09:45:40 -0600, mfanto@gmail.com said:

    >
    >>> The cipher itself is important, too. I assume that you have read some
    >>> articles about the various ciphers, so you most likely use AES. That's
    >>> totally fine, but AES is rather slow, compared to some older ciphers.
    >>> If performance is important, use Blowfish instead. As for AES, no
    >>> practically exploitable security problems have been found in Blowfish so
    >>> far.

    >>
    >> Agreed. Blowfish is very fast and reliable. Its one of the few
    >> remaining ciphers that has not been broken even in the lab...besides,
    >> anything from the BSD community is almost guaranteed to be safe :P.
    >>

    >
    > I wouldn't exactly agree with everything in these statements.
    >
    > Looking at Wei Dai's benchmarks (Crypto++ library) for Blowfish vs AES,
    > you see Blowfish gets roughly 64 MB/Sec while AES (Rijndael) gets 61
    > MB/Sec. This agrees with Brian Gladman's benchmark of AES, about 69
    > MB/Sec. So for performance, I don't think it really matters.


    Many thanks to "Ertugrul Soeylemez" for his quick response and good ideas.

    I spent some time reading up on the "network block device," and it
    sound's really interesting. However, I don't get the impression it
    would be a safe replacement for NFS in my case. More importantly, my
    file server runs Linux, but most of the client computers are Mac OS X.

    I did spend several hours running benchmark tests of various cyphers in
    dm-crypt. I know I've heard many times that blowfish should be faster
    than AES, but on my hardware I was unable to find any combination of
    algorithms and key sizes that was faster than the default AES. I'm
    running kernel 2.6.16 on an AMD Athlon XP 1900+.

    I'm pasting in some iozone test results, below. Sorry if you can't read
    them, but my conculsions are that 1) encryption has a serious
    performance impact, 2) on my hardware, alternate cyphers are not
    significantly faster than the default AES, and 3) encryption causes
    such high CPU use that I wouldn't be able to use it, even if it didn't
    have such a serious disk performance impact.

    Iozone tests with no encryption:

    ../iozone -Rab ext3-plain.xls -i 0 -i 1 -+u -f /mnt/test/iozone.test -q
    64k -n 32M -g 1G -z






    The top row is records sizes, the left column is file sizes
    Writer Report





    4
    8
    16
    32
    64
    32768
    264040
    285567
    300081
    301129
    298322
    65536
    255056
    273653
    287755
    290509
    285828
    131072
    245188
    261827
    272856
    278766
    276478
    262144
    203131
    204851
    197698
    197282
    207523
    524288
    80016
    81624
    78219
    81615
    78454
    1048576
    61207
    61770
    61556
    60959
    61621
    Re-writer Report





    4
    8
    16
    32
    64
    32768
    355817
    380656
    391129
    387209
    377855
    65536
    340930
    362720
    377137
    375100
    361211
    131072
    328581
    348502
    360130
    359315
    353696
    262144
    131226
    130883
    131787
    132920
    132310
    524288
    52863
    74527
    67778
    51289
    75855
    1048576
    48231
    50748
    51745
    62187
    61796
    Reader Report





    4
    8
    16
    32
    64
    32768
    488513
    497298
    520350
    521899
    511927
    65536
    491580
    497117
    521206
    526397
    514395
    131072
    494573
    496774
    523642
    531229
    518110
    262144
    493790
    495826
    524605
    530044
    514614
    524288
    54988
    55473
    55473
    55085
    55473
    1048576
    55198
    55153
    55219
    55449
    55492
    Re-reader Report





    4
    8
    16
    32
    64
    32768
    493211
    500053
    522874
    526393
    514088
    65536
    494425
    497369
    524309
    529412
    514965
    131072
    494689
    502233
    525589
    532123
    519607
    262144
    495064
    499728
    526874
    532074
    516017
    524288
    55473
    55473
    55473
    55473
    55473
    1048576
    55441
    55493
    55463
    55546
    54365


    With the default AES encryption:

    ../iozone -Rab ext3-aes.xls -i 0 -i 1 -+u -f /mnt/test/iozone.test -q
    64k -n 32M -g 1G -z






    The top row is records sizes, the left column is file sizes
    Writer Report





    4
    8
    16
    32
    64
    32768
    184331
    192064
    198077
    194988
    193968
    65536
    64951
    66888
    67543
    67607
    66825
    131072
    36561
    35282
    35354
    35424
    35253
    262144
    35028
    34398
    33882
    34462
    34507
    524288
    30709
    26084
    26801
    28726
    26901
    1048576
    23038
    23232
    22604
    26984
    26235
    Re-writer Report





    4
    8
    16
    32
    64
    32768
    325230
    337943
    346063
    338351
    328372
    65536
    78827
    78837
    79349
    79039
    78450
    131072
    38176
    38360
    38504
    38402
    38237
    262144
    36297
    35992
    35894
    35829
    35571
    524288
    31713
    33478
    36554
    36765
    32705
    1048576
    25383
    24390
    26651
    26140
    27279
    Reader Report





    4
    8
    16
    32
    64
    32768
    490458
    497532
    523374
    528592
    513139
    65536
    493453
    498407
    523776
    529828
    513403
    131072
    493622
    498776
    524560
    531734
    514928
    262144
    493990
    498404
    524787
    532042
    515247
    524288
    22629
    22302
    22793
    22789
    22624
    1048576
    22541
    22591
    22605
    22613
    22497
    Re-reader Report





    4
    8
    16
    32
    64
    32768
    492951
    500366
    526545
    532137
    516372
    65536
    493623
    501949
    526960
    530995
    514548
    131072
    494374
    501520
    528488
    533987
    516462
    262144
    494473
    506532
    525620
    533844
    516324
    524288
    22752
    22784
    22809
    22808
    22697
    1048576
    22521
    22640
    22624
    22345
    22493


    With Blowfish encryption:

    ../iozone -Rab ext3_bf_plain.xls -i 0 -i 1 -+u -f /mnt/test/iozone.test
    -q 64k -n 32M -g 1G -z






    The top row is records sizes, the left column is file sizes
    Writer Report





    4
    8
    16
    32
    64
    32768
    169170
    184418
    185902
    185879
    184936
    65536
    58929
    59524
    59564
    59503
    59386
    131072
    17041
    17881
    19804
    17064
    17893
    262144
    17962
    18573
    18610
    18557
    18092
    524288
    16554
    19520
    17120
    15691
    21411
    1048576
    18213
    17811
    15262
    18303
    18249
    Re-writer Report





    4
    8
    16
    32
    64
    32768
    324153
    338578
    338809
    335061
    324750
    65536
    69320
    70230
    70123
    70070
    69341
    131072
    17383
    19251
    19216
    18579
    20690
    262144
    17330
    24002
    31029
    31062
    19470
    524288
    19788
    17113
    19049
    22409
    24742
    1048576
    16787
    17370
    17109
    17142
    17184
    Reader Report





    4
    8
    16
    32
    64
    32768
    491502
    501109
    520547
    523157
    509547
    65536
    493293
    500985
    524183
    524619
    512236
    131072
    492683
    497984
    520106
    529470
    514702
    262144
    494144
    500762
    522769
    530761
    512409
    524288
    29502
    29786
    29654
    29571
    29531
    1048576
    29267
    29453
    29478
    29518
    29197
    Re-reader Report





    4
    8
    16
    32
    64
    32768
    494134
    505303
    523878
    525717
    511376
    65536
    493416
    505226
    526093
    527826
    514908
    131072
    493705
    500783
    525399
    528071
    515790
    262144
    494159
    505580
    523865
    531514
    512359
    524288
    29589
    29820
    29739
    29672
    29577
    1048576
    29122
    29433
    29528
    29529
    29257


+ Reply to Thread