Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've encrypted my Transcend Jetflash flash drive (16 GB, USB2, ext2). Before the operation, the flash drive's speed was:

# dd if=/dev/zero of=/media/JetFlash/file bs=1M count=256

Results with: 26,5 s, 10,1 Mb/s

Then I encrypted it:

# losetup -e AES128 /dev/loop1 /dev/sdb
# mkfs -t ext2 /dev/loop1
# losetup -d /dev/loop1
# mkdir /mnt/tmp
# mount /dev/sdb -o loop=/dev/loop1,encryption=AES128 /mnt/tmp -t ext2
# losetup -e AES128 /dev/loop1 /dev/sdb

And I've executed the same command:

# dd if=/dev/zero of=/mnt/tmp/file bs=1M count=256

Results with: 11,98 s, 22,4 Mb/s

For AES256 the result was: 12,83 s, 20,9 Mb/s

Can somebody explain what's happening? Why does an encrypted flash drive works twice as fast?

share|improve this question

migrated from Jun 23 '11 at 13:47

This question came from our site for professional and enthusiast programmers.

I think that's not a programming related question and therefore the wrong place to ask. – DanielB Jun 23 '11 at 10:05

Some guesses:

  1. The encryption device is compressing before encrypting.

  2. Writing ones to flash is faster than writing zeros.

share|improve this answer
Do you've a source? – Lekensteyn Jun 23 '11 at 13:49
@Lekensteyn No, just guessing. Compression before encryption is good practice. – Peter G. Jun 23 '11 at 20:34
I do think that compression is something for the filesystem, not the encryption itself? Do you've a source for your second guess? It sounds a little weird. – Lekensteyn Jun 23 '11 at 20:45
I know there have been encryption schemes in the past that compressed. Since the encryption code is inserting itself in the file access path the way it is, compression at the same time is fairly trivial. – Daniel R Hicks Jan 7 '12 at 13:54
And, yes, randomizing the data (as encryption does) may allow faster writing to a flash -- several possible mechanisms for that. – Daniel R Hicks Jan 7 '12 at 13:56

I guess it has to do with write cache, the LUKS layer might act as a cache too, but in the end, it's still limited by the disk speed.

Try writing a bigger file, it should give more realistic results. To test the time needed for writing to the flash drive, run a sync command after doing the dd command. Now measure the time before running dd and after dd using the date program.

share|improve this answer

You must log in to answer this question.