Hi!
I hacked libgcrypt a bit to see how to increase the symmetrical cipher
performance. This should benefit all architecture except for Padlock,
which I have not yet changed.
The current SVN has the changes for AES in CFB and CBC mode. On my box
it gives about 25% speedup with the benchmark tool. That tool has two
new options:
--large-buffers
passes larger blocks of data to the encryption function
and reduces the loop count instead.
--cipher-repetitions N
may be used to increase the loop count by a factor N.
This is gives more accurate timings on fas machines.
Example usage:
tests/benchmark --cipher-repetition 10 cipher aes aes192 aes256
I did a real work test with gpg2 on a 2.9GB MPEG file. First a plain
store operation to see the I/O overhead.
$ time gpg2 --store -z0 -v --batch --passphrase 'test'\
<video/Rockpalast-The_Who.mpg >/dev/null
gpg: writing to stdout
real 1m47.123s
user 0m5.112s
sys 0m5.232s
So this gives us a mere 5 seconds. Now with AES-128 using a stock
libgcrypt 1.4.0:
$ time gpg2 -c --cipher aes -z0 -v --batch --passphrase 'test' \
<video/Rockpalast-The_Who.mpg >/dev/null
gpg: using cipher AES
gpg: writing to stdout
real 3m58.025s
user 2m53.814s
sys 0m5.968s
Yields 73 seconds. Again with the latest libgcrypt:
$ time gpg2 -c --cipher aes -z0 -v --batch --passphrase 'test' \
<video/Rockpalast-The_Who.mpg >/dev/null
gpg: using cipher AES
gpg: writing to stdout
real 3m22.304s
user 2m19.503s
sys 0m5.852s
Yields 139 seconds. Comparing the corrected user times
173 - 5 = 168
139 - 5 = 134
shows that encryption is about 25% faster in CFB mode.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
I hacked libgcrypt a bit to see how to increase the symmetrical cipher
performance. This should benefit all architecture except for Padlock,
which I have not yet changed.
The current SVN has the changes for AES in CFB and CBC mode. On my box
it gives about 25% speedup with the benchmark tool. That tool has two
new options:
--large-buffers
passes larger blocks of data to the encryption function
and reduces the loop count instead.
--cipher-repetitions N
may be used to increase the loop count by a factor N.
This is gives more accurate timings on fas machines.
Example usage:
tests/benchmark --cipher-repetition 10 cipher aes aes192 aes256
I did a real work test with gpg2 on a 2.9GB MPEG file. First a plain
store operation to see the I/O overhead.
$ time gpg2 --store -z0 -v --batch --passphrase 'test'\
<video/Rockpalast-The_Who.mpg >/dev/null
gpg: writing to stdout
real 1m47.123s
user 0m5.112s
sys 0m5.232s
So this gives us a mere 5 seconds. Now with AES-128 using a stock
libgcrypt 1.4.0:
$ time gpg2 -c --cipher aes -z0 -v --batch --passphrase 'test' \
<video/Rockpalast-The_Who.mpg >/dev/null
gpg: using cipher AES
gpg: writing to stdout
real 3m58.025s
user 2m53.814s
sys 0m5.968s
Yields 73 seconds. Again with the latest libgcrypt:
$ time gpg2 -c --cipher aes -z0 -v --batch --passphrase 'test' \
<video/Rockpalast-The_Who.mpg >/dev/null
gpg: using cipher AES
gpg: writing to stdout
real 3m22.304s
user 2m19.503s
sys 0m5.852s
Yields 139 seconds. Comparing the corrected user times
173 - 5 = 168
139 - 5 = 134
shows that encryption is about 25% faster in CFB mode.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel