Prev: Steganography with drawings
Next: The National Socialist Agency Goes Green
From: Thomas Pornin on 19 Feb 2010 11:20
According to Maaartin <grajcar1(a)seznam.cz>:
> byte[] and int[] at the same time, which is easy (although not
> portable) in C using pointer casts.

Actually it is not that easy, because it creates aliasing issues, which
means that the code is prone to break when newer compiler versions
decide to implement more aggressive optimization. These issues can be
avoided but not easily.

As for the decoding of bytes into 32-bit values, I find it to be a
minor part of the performance cost in a typical Java implementation
of hash functions. I have measured, see sphlib.


> Wouldn't using something like Poly1305 in Java be a good idea? I've
> seen no implementation, but I'm quite sure it could be done without
> much effort.

There may be usability issues. Poly1305 requires a 128-bit nonce. Proper
encryption (whether CTR or CBC mode) also requires a nonce (usually
called "IV"). As far as I know, using the same nonce for both usages
could be a problem. So that you have to attach two 128-bit nonces to the
encrypted message, instead of one for GCM or AES/CTR+HMAC. Depending on
the situation, the extra nonce may or may not be a problem.

Also, GCM appears to be able to do its complete job with a single AES
key for both encryption and MAC. Poly1305 requires its own 32-byte key,
so you must have three times the key material. Expanding a 128-bit key
into 384 bits worth of key material can be done with a PRF (a hash
function with a 384-bit output would do the trick) but that's additional
code. For code compactness, simplicity and verifiability (GCM has a
standard which precisely tells where each bit goes, and that's a very
valuable asset), GCM seems best. Conceptually, GCM is the offspring of
both CTR mode and Poly1305-style MAC, with all the pesky details ironed
out, so it seems best to use it rather than its moral ancestors.


--Thomas Pornin
From: Paul Rubin on 19 Feb 2010 14:20
Thomas Pornin <pornin(a)bolet.org> writes:
> HMAC works at the speed of the underlying hash function and beats
> software AES hands down...,

Hmm, here are the speeds I get on my T9300 (2.5 ghz) from "openssl speed":

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 76968.86k 83848.49k 85929.47k 180960.32k 182779.90k
sha1 45098.20k 122558.93k 250669.40k 339154.60k 380199.21k
sha256 32903.52k 71727.77k 121992.05k 148277.59k 158206.63k
hmac(md5) 34650.25k 108850.92k 258416.42k 397975.03k 476004.52k

Openssl 1.0.0-fips-beta4 doesn't seem to have a built-in benchmark for
HMAC-SHA1 or HMAC-SHA256. You're right that HMAC-SHA1 is a lot faster
than AES-CBC for long messages. It suffers a bit for short messages
because of the extra hash. SHA1 itself also suffers for short messages
because of the extra call to the compression function. SHA256 is (at
least in the openssl implementation) not much faster than AES even for
long messages. Both of the SHA's will cause some code and data bloat
(another algorithm, with its own tables and constants) compared with
EAX, which uses AES for both encryption and authentication.

It might be useful for the OWASP folks to look at NACL as another API to
draw some inspiration from, although its motivation is not quite the
same and I wouldn't suggest copying it outright:

http://nacl.cace-project.eu/index.html
From: Thomas Pornin on 19 Feb 2010 16:16
According to Paul Rubin <no.email(a)nospam.invalid>:
> Hmm, here are the speeds I get on my T9300 (2.5 ghz) from "openssl speed":
>
> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
> aes-128 cbc 76968.86k 83848.49k 85929.47k 180960.32k 182779.90k

There is something strange here: the jump from 86 to 181 MB/s between
256- and 1024-byte messages is quite surprising. This would deserve
some investigation. My OpenSSL version is older (0.9.8g) and yields:

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 102319.33k 106607.15k 108477.73k 108667.90k 108691.46k

which looks more "natural".

Could you try sphlib on your system ? It includes a benching program.
Apart from the SHA family, Tiger, RadioGatun and Shabal should prove
to be fast, and are included in sphlib.


--Thomas Pornin
From: Paul Rubin on 19 Feb 2010 20:09
Thomas Pornin <pornin(a)bolet.org> writes:
>> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
>> aes-128 cbc 76968.86k 83848.49k 85929.47k 180960.32k 182779.90k
>
> There is something strange here: the jump from 86 to 181 MB/s between
> 256- and 1024-byte messages is quite surprising.

You're right, I just started using this version and didn't notice that
jump. It happens at all three key sizes:

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 76938.35k 84146.90k 85876.39k 181577.73k 182889.13k
aes-192 cbc 65388.29k 70588.40k 71645.01k 153021.78k 154269.01k
aes-256 cbc 56421.30k 60400.62k 61251.24k 131616.88k 132300.80k

In fact there is a similar jump with md5 and almost as pronounced a jump
with sha1. Hmm, maybe this is an artifact of my laptop power
management, which I think runs the cpu at a reduced speed until it
notices that it's doing something compute intensive. I'll see if I can
figure out how to turn that off and run the speed test again.

> Could you try sphlib on your system ?

Can you tell me where to get it? I found some possible links on
www.crypto-hash.fr but it's not immediately obvious what the right one is.

Thanks.
From: Thomas Pornin on 20 Feb 2010 08:51
According to Paul Rubin <no.email(a)nospam.invalid>:
> Can you tell me where to get it? I found some possible links on
> www.crypto-hash.fr but it's not immediately obvious what the right one is.

http://www.crypto-hash.fr/modules/wfdownloads/singlefile.php?cid=13&lid=10

Then click on the floppy disk icon, or the "Telechargez maintenant" link
(it means "download now" in French).


--Thomas Pornin
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Steganography with drawings
Next: The National Socialist Agency Goes Green