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

[Viktor Dukhovni]

> On Dec 29, 2016, at 9:36 PM, Schmicker, Robert  
> wrote:
> 
> However, as soon as I make a call to my cipher in test.c I get a linker error 
> and gcc is unable to find any of my functions.

Edit util/libcrypto.num and/or util/libssl.num, only the symbols listed there
are exported by the library shared objects.

-- 
Viktor.

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

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

[Schmicker, Robert]

Hello,

I am attempting to add a new cipher into the crypto library. I have done the 
following so far…

1. Added my code to the openssl/crypto folder
2. Created a build.info for make to compile my code (created 
this based off of openssl/crypto/dh’s build.info)
3. Added my cipher name to the list of ciphers to compile in Configure
4. Compiled and installed all code without errors and object files for my new 
cipher are created in openssl/crypto/mycipher/
5. Created a test.c file that verifies that the library is installed and 
working properly by generating a MD5 hash of a string
Compiled as:
gcc test.c -I/usr/local/openssl/include/openssl/ -o test -lcrypto -lssl -Wall
6. I am able to properly include  in my test.c file

However, as soon as I make a call to my cipher in test.c I get a linker error 
and gcc is unable to find any of my functions.

It seems that the header file I have in the openssl/include folder isn’t being 
linked somehow to my code in the openssl/cypto folder.

I feel like I’m missing a step here…

Any help is much appreciated!

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

Re: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

[James Bottomley]

On Mon, 2016-12-26 at 21:13 +0100, Nikos Mavrogianopoulos wrote:
> My comment was on the claim of extendability of the format which as I
> explained it is simply not true. As for example I already gave the
> key usage extension. I am fine however with a non extendable format
> as you proposed. 

OK, so I think the version is now superfluous, since if anything gets
added it can be recognised by the tag and things not ready to parse
that tag can reject it.

That makes the final form

 TPMKey ::= SEQUENCE {
typeOBJECT IDENTIFIER
emptyAuth   [0] EXPLICIT BOOLEAN OPTIONAL
parent  [1] EXPLICIT INTEGER OPTIONAL
pubkey  [2] EXPLICIT OCTET STRING OPTIONAL
privkey OCTET STRING
 }

I'll code the v2 patch using this form.

James

> On December 26, 2016 7:13:40 PM GMT+01:00, James Bottomley <
> james.bottom...@hansenpartnership.com> wrote:
> > On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote:
> > > I'd like both backwards and forward compatibility actually,
> > > exactly
> > > like x509. If an informational field is added like the key usage
> > > that
> > > I mentioned, I doubt you'd like all the previous consumers
> > > incompatible.
> > 
> > OK, so there's a fundamental difference between a v3 X509
> > certificate
> > and a TPM key: An X509 certificate is a signature over a set of v1
> > TBS
> > data, a public key and a bundle of attributes.  To verify the
> > certificate or extract the key, you don't need to know what the
> > attributes are, so you can still "use" the certificate in that
> > form. 
> > However, you can't get the v1 tool to obey the v3 constraints on
> > the
> > certificate because it doesn't understand them.
> > 
> > The ASN.1 description of a TPM key contains the actual binary
> > representation of the key plus a set of information which explains
> > to
> > the consuming code how to use the key.  Since I can't think of a
> > way of
> > making use of the key without understanding all of the information
> > about how to use it, I think it is beneficial that v1 consumers
> > don't
> > try to use v2 key information because the resulting failure will
> > excite
> > the TPM's dictionary attack protection.
> > 
> > I gave an example of one such extension: policy authorisations, but
> > they're definitely of the "if you don't understand these, you can't
> > use
> > the key" variety.  Perhaps if you can give an example of a
> > potentially
> > compatible extensions it would help me to see your point and give
> > us a
> > means of moving forwards.
> > 
> > Thanks,
> > 
> > James
> > 
> > >  For other extensions which make the structure totally
> > > incompatible
> > > you can use the critical flag. Anyway even the original struct is
> > > OK,
> > > it is exactly like any other key structs we have.
> 

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