How is it failing?  When and what error?  Are you the client or server?  Which version of TLS?  What SSL library is on the other end?  Can you provide a wireshark trace of the interaction?  You can send that to me, todd @ yassl.com .  Thanks.

Four things:

1) Since you have a 64bit type available there's no reason to define MP_8BIT or MP_16BIT.  Try removing those.

2) But it sounds like the problem is with memory.  MakeSigner(), mp_init(), and mp_grow() all have one thing in common, dynamic memory use.

3) You could also try defining USE_FAST_MATH and compiling tfm.c in place of integer.c.  Recompile everything and see how that goes.  It removes dynamic memory use from the big integer library but if you truly have a dynamic memory problem it will likely just show up someplace else.

4) Try running the code on a "full" system where you can use a memory debugger to track down any potential problems.

Are you loading a trusted cert?  What is the depth of the chain?

I'm not positive CyaSSL's implementation is wrong.  The beginning of page 64 says "A particular certification path may not, however, be appropriate for all applications.  Therefore, an application MAY augment this algorithm to further limit the set of valid paths."

Though you're the 2nd person to request a less constrained augmented policy.  It's now on our list of repeated requests but nothing has been changed at the moment.  We'll probably add this feature as an option to CyaSSL 1.9.0.

If you add those 3 function declarations to cyassl/include/openssl/ssl.h at the bottom and then blank implementations to the bottom of cyassl/src/ssl.c you should get past the ./configure process which will allow you see the total number of missing functions and what they are.  That will allow us to see how much work it is and the best way to proceed.

Are you compiling integer.c or tfm.c (with the USE_FAST_MATH option)?

If you are using fast math try defining TFM_TIMING_RESISTANT to reduce the runtime stack size.

If you're using integer.c, which function in that file is causing the crash?

First off, I'd recommend using the latest version, 1.8.0.

wolfSSL does use pointers, it allows flexibility in the design and memory usage.

What do you mean by heavy memory management?  You can use the fast-math library to reduce all dynamic memory use for public key crypto, which is the main consumer of dynamic memory.

NO_FILESYSTEM is completely independent of dynamic memory.

If you want to write your own XMALLOC routine, by all means, write it.  The prototype is in types.h.  You can ignore the "extra" parameters if you wish, or use them however you like.

fp_word needs to be at least twice as big as fp_digit.

So fp_word should be the biggest size the compiler allows (usually 64 bits, but can be 16, 32, or even 128).

Then fp_digit should be the type that is half that size, 32 bits in the normal case.

You'll need all the source files in wolfssl/src except for sniffer.c, these comprise the TLS/SSL layer.

You'll also need the files you identified from wolfssl/wolfcrypt/src as well as some others.  Which cipher suite are you planning on using?  You'll probably need RSA for authentication.  And you'll probably need asn.c for certificate parsing. You may also need hmac.c, md5.c, and sha.c depending on the cipher suite (and certificate types).

asm.c is only needed if you're using the fastmath library and want assembly optimizations with a supported compiler (GCC style assembly).

integer.o is going to be the biggest object file since it's the biggest source file.  You should optimize for size (-Os for GCC) and remove the frame pointer if possible (-fomit-frame-pointer for GCC).  Depending on your compiler, processor, options, and instruction set you'll probably see this object file anywhere from 20 to 100kB.

I don't.  We typically use what the client has already picked.  Usually the stack is from the OS, the compiler provider, or it's purchased.  I'll ask around though and let you know if I hear of a good one.

It depends.  Some people say not to use a session more than 500 seconds in case the server's private key is compromised.  Some say not to send more than a certain amount of data, certainly not more than 4 GB.  If you control the server and know the private key is secure you don't really gain much by continually starting and stopping a session unless you're transferring large amounts of known plaintext data.

wolfSSL can create public or private keys.  Certificates are only public in the SSL domain.  And more than the public key is needed to create/sign a public certificate.  All of the common name elements and days valid are needed in addition at the minimum.  Maybe wolfSSL will add a cert ready for signing type structure that isn't x.509 request standard, that's a lot of ASN.1/X.509 code that doesn't add much to our embedded SSL product.  I'll keep that in mind.