Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?

2017-01-12 Thread Salz, Rich 
> Understood.  Can you further clarify whether you would like to maintain the 
> existing 20-year-old hand-rolled hash function for that purpose or are open 
> to using a more modern hash (not necessarily SIPhash; there are also things 
> like the Jenkins hash to consider)?

Because it works, because nobody has looked at our touched that code, because 
there are no security concerns and it's unclear if the speed gain(s) make a 
difference.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?

2017-01-12 Thread Benjamin Kaduk 
On 01/11/2017 08:43 AM, Richard Levitte wrote:
> A note: I have absolutely nothing against the addition of SIPhash in
> our collection of hash algos.  My scepticism was only in regards to
> using it as a string hasher for our hash tables indexes.
>

Understood.  Can you further clarify whether you would like to maintain
the existing 20-year-old hand-rolled hash function for that purpose or
are open to using a more modern hash (not necessarily SIPhash; there are
also things like the Jenkins hash to consider)?

-Ben
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-commits] UI_METHOD

2017-01-12 Thread Richard Levitte 
In message <9da4cbdc-7437-b942-0d2e-e05808cd1...@akamai.com> on Thu, 12 Jan 
2017 11:17:10 -0600, Benjamin Kaduk  said:

bkaduk> On 01/11/2017 11:27 AM, Richard Levitte wrote:
bkaduk> 
bkaduk> The branch master has been updated
bkaduk>via  66ed24b1624606593a23c9fe78d459718d26409c (commit)
bkaduk>via  78b19e90b4aade1ffdf8d918277910b01dac1d76 (commit)
bkaduk>via  cc10f2275594eac2bcdaa218c1d6f672c2b891b7 (commit)
bkaduk>via  3ab3c8cb274aca1b5c0fbf83af96e49baf422708 (commit)
bkaduk>via  0fe1fc858a0519c3866c0d2e88513e677b674926 (commit)
bkaduk>via  18cfc668eae2c296e9bc90ffc989d9bbe61cc82f (commit)
bkaduk>via  a223ffe6d35209c59ed498ee89d1bac6e82e2ac2 (commit)
bkaduk>via  264b2d92511572a247ecb673d61ff385deb9eb8d (commit)
bkaduk>   from  5eeb6c6e562937dcfdd4b79619a699a118deadba (commit)
bkaduk> 
bkaduk> +static int ui_method_data_index()
bkaduk> +{
bkaduk> +static int idx = -1;
bkaduk> +
bkaduk> +if (idx == -1)
bkaduk> +idx = CRYPTO_get_ex_new_index(CRYPTO_EX_INDEX_UI_METHOD,
bkaduk> +  0, NULL,
bkaduk> +  ui_new_method_data,
bkaduk> +  ui_dup_method_data,
bkaduk> +  ui_free_method_data);
bkaduk> 
bkaduk> Should this have some synchronization around it to prevent concurrent
bkaduk> checks in multiple threads? It looks like we use a lock for our
bkaduk> internal stuff, but a run_once ought to be fine, too.

Good point...  and quite easily done.

Incidently, include/internal/thread_once.h isn't telling the truth
about the return value of RUN_ONCE...  I'll take advantage of that!

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-commits] UI_METHOD

2017-01-12 Thread Benjamin Kaduk 
On 01/11/2017 11:27 AM, Richard Levitte wrote:
> The branch master has been updated
>via  66ed24b1624606593a23c9fe78d459718d26409c (commit)
>via  78b19e90b4aade1ffdf8d918277910b01dac1d76 (commit)
>via  cc10f2275594eac2bcdaa218c1d6f672c2b891b7 (commit)
>via  3ab3c8cb274aca1b5c0fbf83af96e49baf422708 (commit)
>via  0fe1fc858a0519c3866c0d2e88513e677b674926 (commit)
>via  18cfc668eae2c296e9bc90ffc989d9bbe61cc82f (commit)
>via  a223ffe6d35209c59ed498ee89d1bac6e82e2ac2 (commit)
>via  264b2d92511572a247ecb673d61ff385deb9eb8d (commit)
>   from  5eeb6c6e562937dcfdd4b79619a699a118deadba (commit)

> +static int ui_method_data_index()
> +{
> +static int idx = -1;
> +
> +if (idx == -1)
> +idx = CRYPTO_get_ex_new_index(CRYPTO_EX_INDEX_UI_METHOD,
> +  0, NULL,
> +  ui_new_method_data,
> +  ui_dup_method_data,
> +  ui_free_method_data);

Should this have some synchronization around it to prevent concurrent
checks in multiple threads?  It looks like we use a lock for our
internal stuff, but a run_once ought to be fine, too.

-Ben
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [EXTERNAL] Re: use SIPhash for OPENSSL_LH_strhash?

2017-01-12 Thread Hubert Kario 
On Wednesday, 11 January 2017 18:09:04 CET Sands, Daniel wrote:
> Just a note from my own experience way back when:  I tried hashing using
> various algos and measuring bucket use as the main comparison criteria.
> I found that the crypto hashes left a fair number of unused buckets. 

I can explain that only in two ways:
 1. "crypto hashes" were biased
 2. the test used too many buckets compared to number of entries

to put it mildly, option 1 is "unlikely"

so since I don't want to point fingers, I'd say we need more data before we 
can discredit use of cryptographically secure hashes for this use case...

> Of
> course, CRCs were far worse.  What gave the most normal distribution was
> to simply take the bytes 4 at a time as 32-bit integers and simply add
> them.
> 
> Not to say that this is really the holy grail, just pointing out that
> compute speed shouldn't be the only criteria you use for comparison.
> 
> On Wed, 2017-01-11 at 15:43 +0100, Richard Levitte wrote:
> > A note: I have absolutely nothing against the addition of SIPhash in
> > our collection of hash algos.  My scepticism was only in regards to
> > using it as a string hasher for our hash tables indexes.
> > 
> > Cheers,
> > Richard
> > 
> > In message <20170111.153458.1623912899597806811.levi...@openssl.org> on
> > Wed, 11 Jan 2017 15:34:58 +0100 (CET), Richard Levitte
> >  said:
> > 
> > levitte> In message
> > <1e19cdfea8224717b3eee11e2d8ac...@usma1ex-dag1mb1.msg.corp.akamai.com> on
> > Wed, 11 Jan 2017 03:13:39 +, "Salz, Rich"  said:
> > levitte>
> > levitte> rsalz> The needs for OpenSSL's LHASH are exactly what SipHash was
> > designed for: fast on short strings. levitte> rsalz> OpenSSL's hash
> > currently *does not* call MD5 or SHA1; the MD5 code is commented out.
> > levitte> rsalz> Yes, performance tests would greatly inform the decision.
> > levitte>
> > levitte> Done, using the reference siphash implementation.
> > levitte>
> > levitte> https://github.com/levitte/openssl/tree/test-string-hashes
> > levitte>
> > levitte> A run on my laptop gave these results:
> > levitte>
> > levitte> : ; ./util/shlib_wrap.sh apps/openssl speed siphash lhash
> > levitte> Doing lhash for 3s on 16 size blocks: 27635188 lhash's in
> > 3.00s levitte> Doing lhash for 3s on 64 size blocks: 6934726 lhash's
> > in 3.00s levitte> Doing lhash for 3s on 256 size blocks: 1698489
> > lhash's in 3.00s levitte> Doing lhash for 3s on 1024 size blocks:
> > 431185 lhash's in 3.00s levitte> Doing lhash for 3s on 8192 size
> > blocks: 53868 lhash's in 3.00s levitte> Doing lhash for 3s on 16384
> > size blocks: 27041 lhash's in 3.00s levitte> Doing siphash for 3s on
> > 16 size blocks: 22488748 siphash's in 3.00s levitte> Doing siphash
> > for 3s on 64 size blocks: 10485674 siphash's in 3.00s levitte> Doing
> > siphash for 3s on 256 size blocks: 3320898 siphash's in 3.00s levitte>   
> >  Doing siphash for 3s on 1024 size blocks: 894647 siphash's in 3.00s
> > levitte> Doing siphash for 3s on 8192 size blocks: 114170 siphash's
> > in 3.00s levitte> Doing siphash for 3s on 16384 size blocks: 57151
> > siphash's in 3.00s levitte> OpenSSL 1.1.1-dev  xx XXX 
> > levitte> built on: reproducible build, date unspecified
> > levitte> options:bn(64,64) rc4(16x,int) des(int) aes(partial)
> > idea(int) blowfish(ptr) levitte> compiler: gcc -DDSO_DLFCN
> > -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
> > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM
> > -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM
> > -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM
> > -DOPENSSLDIR="\"/usr/local/ssl\""
> > -DENGINESDIR="\"/usr/local/lib/engines-1.1\""  -DDEBUG_UNUSED -Wswitch
> > -DPEDANTIC -pedantic -Wno-long-long -Wall -Wsign-compare
> > -Wmissing-prototypes -Wshadow -Wformat -Wtype-limits -Werror
> > -Wa,--noexecstack levitte> The 'numbers' are in 1000s of bytes per
> > second processed. levitte> type 16 bytes 64 bytes   
> > 256 bytes   1024 bytes   8192 bytes  16384 bytes levitte> lhash  
> > 147387.67k   147940.82k   144937.73k   147177.81k   147095.55k  
> > 147679.91k levitte> siphash 119939.99k   223694.38k  
> > 283383.30k   305372.84k   311760.21k   312120.66k levitte>
> > levitte> So it seems that for short strings, OPENSSL_LH_strhash (*) wins
> > some, levitte> while siphash wins big for larger strings.
> > levitte>
> > levitte> I have no idea how they compare with regard to distribution
> > (which, levitte> considering I ask for the same size output from both,
> > should be the levitte> main factor that affects the sensitivity to hash
> > flooding)... levitte>
> > levitte> Our use of OPENSSL_LH_strhash() is with configuration sections
> > and
> > levitte> names, ASN.1 object names and the

Re: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0

2017-01-12 Thread Hubert Kario 
On Friday, 16 September 2016 17:26:03 CET Hubert Kario wrote:
> I've been running tests on the openssl 1.1.0 release recently and I've
> noticed that if the client doesn't include the supported_groups extension,
> OpenSSL will pick curve with id 0x001d, that is ecdh_x25519, as the curve
> to do ECDHE over.
> 
> While this is not incorrect behaviour according to the standard (it is quite
> explicit that if client doesn't provide this extension, server can pick any
> curve it wants), I'm afraid that this will cause interoperability problems.
> 
> The majority of servers (71%) support *only* prime256v1 curve and of the
> ones that default to ECDHE key exchange nearly 83% will also default to
> this curve. OpenSSL 1.0.2h also defaults to this curve if there are no
> curves advertised by client.
> 
> So it is very likely that any client that doesn't advertise curves will
> expect the server to select prime256v1. At the same time it is very
> unlikely that it will support x25519 (given how new it is).

I've filed a bug on github so that it doesn't fall off the radar...
https://github.com/openssl/openssl/issues/2219

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev