Thanks Paul.  I just checked in a patch yesterday that changes CyaSSL's default certificate generation to SHA-1 with RSA since iOS 5 no longer accepts MD5 with RSA either.  We'll update the CyaSSL test certificates on Monday and have a blog about these changes.

By the way, the echoserver example would probably be easier for you.  It doesn't have client verification and sends an HTTP reply if a GET is received, and runs in a loop. 

Thanks again,
-Todd

Are you trying to implement your own SSL type handshake, only simpler?  If so, the security you think you're getting is almost certianly not as strong as it appears.  In order to ensure proper authentication and encryption SSL is probably the way to go.  I'd recommend using SSL and then transferring the password over the secure channel.

Even if we patched TaoCrypt to support OpenSSL public keys directly (instead of through certificates) it still wouldn't meet your requirement of OpenSSL compatibility since TaoCrypt isn't API compatible with OpenSSL's crypto API.

I take it SSL is too costly?

You're correct.  It didn't make it into 1.9.0.  Though it has made it into our source on github and will make it into the next release, more testing is needed at this point.  You can try it out with:

git clone git@github.com:cyassl/cyassl.git
cd cyassl
./autogen.sh
./configure  (whichever options you use)
make

Thanks eof!  We'll add these this week to the main branch.

SSL_connect() will return success (done) or failure (fatal_error), that's just the way the API was designed.  To see the actual error, call SSL_get_error().  In this case WANT_READ will be converted to SSL_ERROR_WANT_READ for OpenSSL compatibility.  See man SSL_connect for more details (or look online if the SSL man pages aren't installed on your system).

NON_BLOCKING is a define used by the examples.  wolfSSL proper doesn't "know" blocking or non-blocking, it's neutral by design.

The handshake callback is intended for embedded SSL systems for debugging support.  That is, when a good debugger isn't available and sniffing is impractical.  It basically allows a trace of the handshake and won't be helpful for network i/o.

You'll want to use wolfSSL's user I/O callbacks found in cyassl_io.c.  By default, wolfSSL uses EmbedReceive() to get data and EmbedSend() to send data.  But you can write any I/O functions you want and then register them with CyaSSL_SetIORecv() and CyaSSL_SetIOSend().  You can also set a context for each SSL session with CyaSSL_SetIOReadCtx() and CyaSSL_SetIOWriteCtx().  The void* ctx could point to a structure that has information about where the next read or write buffer is, the size, and anything else you may need to track.

Try to follow the the error handling strategy of the default send/recv functions for maximum compatibility.  That is, if wolfSSL calls your Recv function and no data is ready and you don't want to block, just return IO_ERR_WANT_READ.  Then when you're notified by your network callback that I/O is ready just call the wolfSSL function again that didn't have data ready, like SSL_read() or SSL_connect() and it will pick up where it left off.

Thanks, you're right, having SSL_ERROR_NONE when result > 0 is more compatible with OpenSSL.  I've put it into our latest patch of our embedded SSL library which should be available tomorrow on github.

You can now build CyaSSL 1.9.0+ with the latest sources available from curl at git clone git://github.com/bagder/curl.git.

To use it.
CyaSSL steps:
1) get CyaSSL 1.9.0
2) ./configure --disable-static
3) make
4) sudo make install

curl steps
1) git latest curl sources from above link
2) ./buildconf
3) ./configure --disable-shared --with-cyassl --without-ssl --enable-debug
4) make

You'll now have a new curl with CyaSSL in src/.  If you're not loading all the CA certificates you need to verify sites for testing use -k to do insecure mode, e.g.,

./curl https://gmail.google.com -k

Definitely.  Though to be a perfect drop in replacement we'd have to implement the several thousand function calls they support, and that would probably negate the size advantage.

Pros:  Not having to implement the OS specific locking/unlocking of the session cache mutex in a multi-threaded environment.

Cons:  For the client the con isn't too bad unless the client would otherwise be doing a lot of session resumptions and/or there are device constraints making public key operations extremely slow on the device.  For the server, the cons are pretty big unless there are a low number of clients and they aren't doing session resumption.

I know someone put CyaSSL into a VPN, though I'm not sure I ever learned which one.