Re: Crypto tangle

2017-01-27 Thread Hal Murray
dfoxfra...@gmail.com said: > Setting aside any countervailing considerations concerning dependencies and > binary footprint, yes. MAC computation lives in the real-time critical > section where speed means precision so any optimization we can get here is a > win. Just to make sure we are all on

Re: Crypto tangle

2017-01-27 Thread Greg Rubin
If you are deeply concerned with speed, the older (less recommended) interfaces for MD5 and SHA1 in OpenSSL are faster than the newer EVP interface. (I don't have the numbers in front of me, but you may want to do some benchmarking to see if you care.) https://www.openssl.org/docs/man1.0.1/crypto/

Re: Crypto tangle

2017-01-27 Thread Eric S. Raymond
Gary E. Miller : > Yo Mark! > > On Fri, 27 Jan 2017 18:17:40 + > Mark Atwood wrote: > > > Can libsodium upstream take a pull request that adds the hash > > functions that we need? > > My understanding is that they considered md5 and sha1 too dangerous to > use and would not be complicit wit

Re: Crypto tangle

2017-01-27 Thread Kurt Roeckx
On Fri, Jan 27, 2017 at 08:38:06PM +0100, Achim Gratz wrote: > Eric S. Raymond writes: > > It depends on which MAC algorithms we want to support, a question I've > > opened > > in a recent email. It looks like libsodium's support for hash functions in > > our set is limited to SHA-2, so libsodium

Re: Crypto tangle

2017-01-27 Thread Achim Gratz
Eric S. Raymond writes: > It depends on which MAC algorithms we want to support, a question I've opened > in a recent email. It looks like libsodium's support for hash functions in > our set is limited to SHA-2, so libsodium can't replace OpenSSL. SHA1 will go out of OpenSSL sooner than you might

Re: Crypto tangle

2017-01-27 Thread Daniel Franke
On 1/27/17, Mark Atwood wrote: > Ah, now I get it. They do support new good stuff, they don't support old > bad stuff. > > Daniel, are you suggesting we want to use OpenSSL instead of inline C of > md5 and sha1 to take advantage of optimized asm and accellerated > implementations? Setting aside

Re: Crypto tangle

2017-01-27 Thread Mark Atwood
Ah, now I get it. They do support new good stuff, they don't support old bad stuff. Daniel, are you suggesting we want to use OpenSSL instead of inline C of md5 and sha1 to take advantage of optimized asm and accellerated implementations? ..m On Fri, Jan 27, 2017 at 10:43 AM Gary E. Miller wro

Re: Crypto tangle

2017-01-27 Thread Gary E. Miller
Yo Mark! On Fri, 27 Jan 2017 18:17:40 + Mark Atwood wrote: > Can libsodium upstream take a pull request that adds the hash > functions that we need? My understanding is that they considered md5 and sha1 too dangerous to use and would not be complicit with anyone doing do. RGDS GARY ---

Re: Crypto tangle

2017-01-27 Thread Mark Atwood
Can libsodium upstream take a pull request that adds the hash functions that we need? On Fri, Jan 27, 2017 at 7:40 AM Eric S. Raymond wrote: > Hal Murray : > > We currently have 2 and 1/4 crypto packages. That seems like the sort of > > things you like to clean up. > > Yes. > > > I would have s

Re: Crypto tangle

2017-01-27 Thread Eric S. Raymond
Hal Murray : > We currently have 2 and 1/4 crypto packages. That seems like the sort of > things you like to clean up. Yes. > I would have said we have 2 1/2, but somebody deleted half of the 1/2. I > assume that was part of the --enable-crypto cleanup. There used to be > routines in libisc

Crypto tangle

2017-01-27 Thread Hal Murray
We currently have 2 and 1/4 crypto packages. That seems like the sort of things you like to clean up. I would have said we have 2 1/2, but somebody deleted half of the 1/2. I assume that was part of the --enable-crypto cleanup. There used to be routines in libisc for MD5 and SHA1. md5.c is