Re: [openssl-dev] Linker error when adding new cipher in crypto folder

[Schmicker, Robert]

rschm2> Hello,
rschm2>
rschm2> I am attempting to add a new cipher into the crypto library. I have
rschm2> done the following so far?
rschm2>
rschm2> 1. Added my code to the openssl/crypto folder
rschm2> 2. Created a build.info for make to compile my code 
(created this
rschm2> based off of openssl/crypto/dh?s build.info)
rschm2> 3. Added my cipher name to the list of ciphers to compile in Configure
rschm2> 4. Compiled and installed all code without errors and object files for
rschm2> my new cipher are created in openssl/crypto/mycipher/
rschm2> 5. Created a test.c file that verifies that the library is installed
rschm2> and working properly by generating a MD5 hash of a string
rschm2> Compiled as:
rschm2> gcc test.c -I/usr/local/openssl/include/openssl/ -o test -lcrypto -
rschm2> lssl -Wall
rschm2> 6. I am able to properly include  in my test.c
rschm2> file
rschm2>
rschm2> However, as soon as I make a call to my cipher in test.c I get a
rschm2> linker error and gcc is unable to find any of my functions.
rschm2>
rschm2> It seems that the header file I have in the openssl/include folder
rschm2> isn?t being linked somehow to my code in the openssl/cypto folder.
rschm2>
rschm2> I feel like I?m missing a step here?
rschm2>
rschm2> Any help is much appreciated!

levitte>On way is to, as already mentioned, edit util/libcrypto.num.  The
levitte>other is to edit util/mkdef.pl and then run 'make update'.  In
levitte>mkdef.pl, you'll find a bunch of lines like this:

levitte>   $crypto.="include/openssl/whatever.h"

levitte>Simply add a line like that for mycipher.h.

levitte>(note: mkdef.pl might be a bit picky sometimes)

levitte>Cheers,
levitte>Richard

levitte>--
levitte>Richard Levitte levi...@openssl.org
levitte>OpenSSL Project http://www.openssl.org/~levitte/

Hello,

I would just like to thank Richard Levitte and Viktor for their help as I was 
finally able to figure it out. In case anyone else would like this same process 
I have included some general documentation below:

1) git clone openssl project
2) edit util/mkdef.pl for  header 
file (header file must be extern and have (void) in function declaration if no 
arguments are being passed)
3) edit Configure (line 313ish) and add in crypto function amongst others
4) create build.info under /crypto/mycipher/ (follow other 
crypto build.info’s to create)
5) ./config
6) make update
7) make -j 

Rob

On Dec 31, 2016, at 5:52 PM, 
openssl-dev-requ...@openssl.org wrote:

Re: Linker error when adding new cipher in crypto folder

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

[openssl-dev] build.info documentation

[Schmicker, Robert]

Hello,

Can anyone here point me in the direction to some documentation on 
build.info files?

For the most part I’m creating mine using examples from other crypto ciphers 
but could use some more in depth explanation of what is going on when it is 
being parsed.

More specifically, I’m attempting to create a build.info 
file that will trigger a Makefile in a subdirectory for my new encryption 
cipher to later include using the INCLUDE[…].

Thank you in advance to any advice or help!
Rob
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

We don’t need the full output width of a good hash function, but for _this_ 
purpose (as far as I understand) we don’t need the strength of a good hash 
function either – and we surely don’t need the unnecessary performance hit of a 
good hash where we don’t need a good hash.

 

Or am I missing something?

— 

Regards,

Uri

 

 

On 1/10/17, 2:19 PM, "openssl-dev on behalf of Benjamin Kaduk" 
 wrote:

 

On 01/10/2017 12:31 PM, Richard Levitte wrote:

 
Benjamin Kaduk  skrev: (10 januari 2017 18:48:32 CET)
On 01/09/2017 10:05 PM, Salz, Rich wrote:
Should we move to using SIPHash for the default string hashing
function in OpenSSL?  It’s now in the kernel
https://lkml.org/lkml/2017/1/9/619
 
Heck, yes! 
-Ben
I fail to see what that would give us. OPENSSL_LH_strhash() is used to get a 
reasonable index for LHASH entries. Also SIPhash gives at least 64 bits 
results, do we really expect to see large enough hash tables to warrant that? 
 

We don't need to use the full output width of a good hash function.


My main point is, "why would we want to ignore the last 20 years of advancement 
in hash function research?"  Section 7 of the siphash paper 
(https://131002.net/siphash/siphash.pdf) explicitly talks about using it for 
hash tables, including using hash table indices H(m) mod l.

-Ben



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Short, Todd]

I think I might have an init/update/final version of siphash24 lying around 
somewhere that would be compatible with OpenSSL’s EVP_PKEY mechanism (similar 
to Poly1305, in that it needs a key).
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jan 10, 2017, at 4:55 PM, Richard Levitte 
> wrote:



Benjamin Kaduk > skrev: (10 januari 
2017 20:19:21 CET)
On 01/10/2017 12:31 PM, Richard Levitte wrote:

Benjamin Kaduk > skrev: (10 januari 
2017 18:48:32
CET)
On 01/09/2017 10:05 PM, Salz, Rich wrote:
Should we move to using SIPHash for the default string hashing
function in OpenSSL?  It’s now in the kernel
https://lkml.org/lkml/2017/1/9/619

Heck, yes!
-Ben
I fail to see what that would give us. OPENSSL_LH_strhash() is used
to get a reasonable index for LHASH entries. Also SIPhash gives at
least 64 bits results, do we really expect to see large enough hash
tables to warrant that?


We don't need to use the full output width of a good hash function.

My main point is, "why would we want to ignore the last 20 years of
advancement in hash function research?"  Section 7 of the siphash paper
(https://131002.net/siphash/siphash.pdf) explicitly talks about using
it
for hash tables, including using hash table indices H(m) mod l.

I agree with the advice when one can expect huge tables. The tables we handle 
are pretty small (I think, please correct me if I'm wrong) and would in all 
likelihood not benefit very much if at all from SIPhash's relative safety.

Of course, one can ask the question if someone uses LHASH as a general purpose 
hash table implementation rather than just for the stuff OpenSSL. Frankly, I 
would probably look at a dedicated hash table library first...

Cheers
Richard
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

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

[Richard Levitte]

Benjamin Kaduk  skrev: (10 januari 2017 20:19:21 CET)
>On 01/10/2017 12:31 PM, Richard Levitte wrote:
>>
>> Benjamin Kaduk  skrev: (10 januari 2017 18:48:32
>CET)
>>> On 01/09/2017 10:05 PM, Salz, Rich wrote:
 Should we move to using SIPHash for the default string hashing
 function in OpenSSL?  It’s now in the kernel
 https://lkml.org/lkml/2017/1/9/619

>>> Heck, yes!
>>> -Ben
>> I fail to see what that would give us. OPENSSL_LH_strhash() is used
>to get a reasonable index for LHASH entries. Also SIPhash gives at
>least 64 bits results, do we really expect to see large enough hash
>tables to warrant that? 
>>
>
>We don't need to use the full output width of a good hash function.
>
>My main point is, "why would we want to ignore the last 20 years of
>advancement in hash function research?"  Section 7 of the siphash paper
>(https://131002.net/siphash/siphash.pdf) explicitly talks about using
>it
>for hash tables, including using hash table indices H(m) mod l.

I agree with the advice when one can expect huge tables. The tables we handle 
are pretty small (I think, please correct me if I'm wrong) and would in all 
likelihood not benefit very much if at all from SIPhash's relative safety. 

Of course, one can ask the question if someone uses LHASH as a general purpose 
hash table implementation rather than just for the stuff OpenSSL. Frankly, I 
would probably look at a dedicated hash table library first... 

Cheers 
Richard 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Peter Waltenberg]

Reality check

Others have pointed this out but I don't think it's making it through. 
LHash doesn't need a cryptographic hash and it doesn't have security 
implications. It certainly doesn't need a keyed hash.

LHash does need to be something that's good at distinguishing short text 
strings, that's not necessarilly the same thing as a good cryptographic 
hash, and possibly it's exactly the opposite thing due to the limitted 
incoming symbol space (ascii text).
About the only thing LHash needs is high performance in it's use area. I'd 
suspect that switching MD5 to SHA-1 in the existing algorithm would get 
you that simply because SHA-1 is asm optimized on most platforms now and 
MD5 typically isn't.
I'd suggest that anyone wishing to change this should at least have to 
demonstrate improved performance in the OpenSSL use case before it's 
accepted.

Peter



From:   "Short, Todd" 
To: "openssl-dev@openssl.org" 
Date:   11/01/2017 08:42
Subject:Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?
Sent by:"openssl-dev" 



I think I might have an init/update/final version of siphash24 lying 
around somewhere that would be compatible with OpenSSL’s EVP_PKEY 
mechanism (similar to Poly1305, in that it needs a key).
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jan 10, 2017, at 4:55 PM, Richard Levitte  wrote:



Benjamin Kaduk  skrev: (10 januari 2017 20:19:21 CET)
On 01/10/2017 12:31 PM, Richard Levitte wrote:

Benjamin Kaduk  skrev: (10 januari 2017 18:48:32
CET)
On 01/09/2017 10:05 PM, Salz, Rich wrote:
Should we move to using SIPHash for the default string hashing
function in OpenSSL?  It’s now in the kernel
https://lkml.org/lkml/2017/1/9/619

Heck, yes!
-Ben
I fail to see what that would give us. OPENSSL_LH_strhash() is used
to get a reasonable index for LHASH entries. Also SIPhash gives at
least 64 bits results, do we really expect to see large enough hash
tables to warrant that? 


We don't need to use the full output width of a good hash function.

My main point is, "why would we want to ignore the last 20 years of
advancement in hash function research?"  Section 7 of the siphash paper
(https://131002.net/siphash/siphash.pdf) explicitly talks about using
it
for hash tables, including using hash table indices H(m) mod l.

I agree with the advice when one can expect huge tables. The tables we 
handle are pretty small (I think, please correct me if I'm wrong) and 
would in all likelihood not benefit very much if at all from SIPhash's 
relative safety. 

Of course, one can ask the question if someone uses LHASH as a general 
purpose hash table implementation rather than just for the stuff OpenSSL. 
Frankly, I would probably look at a dedicated hash table library first... 

Cheers 
Richard 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




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

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

[Salz, Rich]

The needs for OpenSSL's LHASH are exactly what SipHash was designed for: fast 
on short strings.
OpenSSL's hash currently *does not* call MD5 or SHA1; the MD5 code is commented 
out.
Yes, performance tests would greatly inform the decision.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Benjamin Kaduk]

On 01/09/2017 10:05 PM, Salz, Rich wrote:
>
> Should we move to using SIPHash for the default string hashing
> function in OpenSSL?  It’s now in the kernel
> https://lkml.org/lkml/2017/1/9/619
> 
>
> Overview at https://131002.net/siphash/
> 
>
>

Instead of this?

%

/*-
unsigned char b[16];
MD5(c,strlen(c),b);
return(b[0]|(b[1]<<8)|(b[2]<<16)|(b[3]<<24));
*/

n = 0x100;
while (*c) {
v = n | (*c);
n += 0x100;
r = (int)((v >> 2) ^ v) & 0x0f;
ret = (ret << r) | (ret >> (32 - r));
ret &= 0xL;
ret ^= v * v;
c++;
}
return ((ret >> 16) ^ ret);

%

Heck, yes!

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

[openssl-dev] x509 extension support

[Freemon Johnson]

Hello,

Can anyone help me in discerning which version of openssl supports
sbgp-autonomousSysNum
and sbgp-ipAddrBlock? If it has been deprecated then providing the
alternative would be greatly appreciated.



A sample openssl.cnf is provided below. When I perform a request for req it
fails because of the objects described above. The version of openssl I am
using when attempting this req generation is version OpenSSL 1.0.2g  1 Mar
2016


[req]default_bits= 2048default_md  =
sha256distinguished_name  = req_dnprompt  =
noencrypt_key = no
[req_dn]CN  = Testbed RPKI root certificate
[x509v3_extensions]basicConstraints=
critical,CA:truesubjectKeyIdentifier= hashkeyUsage
= critical,keyCertSign,cRLSignsubjectInfoAccess   =
@siacertificatePolicies =
critical,1.3.6.1.5.5.7.14.2sbgp-autonomousSysNum   =
critical,@rfc3779_asnssbgp-ipAddrBlock=
critical,@rfc3997_addrs
[sia]1.3.6.1.5.5.7.48.5;URI  =
rsync://example.org/rpki/root/1.3.6.1.5.5.7.48.10;URI =
rsync://example.org/rpki/root/root.mft
[rfc3779_asns]AS.0 = 64496-64511AS.1 = 65536-65551
[rfc3997_addrs]IPv4.0 = 192.0.2.0/24IPv4.1 = 198.51.100.0/24IPv4.2 =
203.0.113.0/24 IPv6.0 = 2001:0DB8::/32



Cheers,

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

Re: [openssl-dev] x509 extension support

[Rob Austein]

At Tue, 10 Jan 2017 09:42:02 -0500, Freemon Johnson wrote:
>
> Can anyone help me in discerning which version of openssl supports
> sbgp-autonomousSysNum and sbgp-ipAddrBlock? If it has been
> deprecated then providing the alternative would be greatly
> appreciated.

RFC 3779 support has been in the code base for going on ten years now,
and as far as I know is still available in all supported versions.

Most likely the problem you're seeing is that the RFC 3779 code isn't
enabled at compile time in the binaries you're using.  Some platforms
enable it, some don't.  You could always try lobbying the maintainer
of whatever packaging you're using (if any), but, failing that, you
may have to build your own binaries, in which case you'll need to
enable RFC 3779 support when you run ./Configure.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Levitte]

Benjamin Kaduk  skrev: (10 januari 2017 18:48:32 CET)
>On 01/09/2017 10:05 PM, Salz, Rich wrote:
>>
>> Should we move to using SIPHash for the default string hashing
>> function in OpenSSL?  It’s now in the kernel
>> https://lkml.org/lkml/2017/1/9/619
>>
>
>>
>> Overview at https://131002.net/siphash/
>>
>
>>
>>
>
>Instead of this?
>
>%
>
>/*-
>unsigned char b[16];
>MD5(c,strlen(c),b);
>return(b[0]|(b[1]<<8)|(b[2]<<16)|(b[3]<<24));
>*/
>
>n = 0x100;
>while (*c) {
>v = n | (*c);
>n += 0x100;
>r = (int)((v >> 2) ^ v) & 0x0f;
>ret = (ret << r) | (ret >> (32 - r));
>ret &= 0xL;
>ret ^= v * v;
>c++;
>}
>return ((ret >> 16) ^ ret);
>
>%
>
>Heck, yes!
>
>-Ben

I fail to see what that would give us. OPENSSL_LH_strhash() is used to get a 
reasonable index for LHASH entries. Also SIPhash gives at least 64 bits 
results, do we really expect to see large enough hash tables to warrant that? 

Cheers 
Richard 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Benjamin Kaduk]

On 01/10/2017 12:31 PM, Richard Levitte wrote:
>
> Benjamin Kaduk  skrev: (10 januari 2017 18:48:32 CET)
>> On 01/09/2017 10:05 PM, Salz, Rich wrote:
>>> Should we move to using SIPHash for the default string hashing
>>> function in OpenSSL?  It’s now in the kernel
>>> https://lkml.org/lkml/2017/1/9/619
>>>
>> Heck, yes!
>> -Ben
> I fail to see what that would give us. OPENSSL_LH_strhash() is used to get a 
> reasonable index for LHASH entries. Also SIPhash gives at least 64 bits 
> results, do we really expect to see large enough hash tables to warrant that? 
>

We don't need to use the full output width of a good hash function.

My main point is, "why would we want to ignore the last 20 years of
advancement in hash function research?"  Section 7 of the siphash paper
(https://131002.net/siphash/siphash.pdf) explicitly talks about using it
for hash tables, including using hash table indices H(m) mod l.

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

Re: [openssl-dev] [TrouSerS-tech] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Ken Goldman]

On 1/3/2017 6:22 PM, James Bottomley wrote:


Note that google took an alternative approach and modified their TSS to
work with a MD5-SHA1 signature:

https://chromium-review.googlesource.com/#/c/420811/

But this requires a modification to the TPM as well, which we can't do.


Right.  It's not a TSS issue.  Modification is futile.  It just passes 
parameters on to the TPM.  The place for this change is the TCG's TPM 
work group.



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