Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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 stackoverflow.com 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
add comment

2 Answers

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
add comment

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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.