1 Reply by pbreed

(2 replies, posted in wolfCrypt)

I've already done that in ECDSA with:

        wc_ecc_export_public_raw(& AccountKey, qx, &qxlen,qy, &qylen);

and the signature with:

     mp_int ri; // destination for r component of signature.
     mp_int si; // destination for s component of signature.
     mp_init(&ri); // initialize r component
     mp_init(&si); // initialize s component
     wc_ret |= wc_ecc_sign_hash_ex(hash, hash_len,&rng, &AccountKey,&ri,&si);

     uint8_t dbuf[64];
     uint32_t rsiz=32;
     uint32_t ssiz=32;

     wc_export_int(&ri,dbuf,(word32 *)&rsiz,32,WC_TYPE_UNSIGNED_BIN);
     wc_export_int(&si,dbuf+32,(word32 *)&ssiz,32,WC_TYPE_UNSIGNED_BIN);

Just did not want to duplicate work if you guys were going to build a library...
Making an ACME client work... its mostly working, just have to clean it up...

Go to forum: wolfCrypt

2 Topic by pbreed

(2 replies, posted in wolfCrypt)

IS there any support for converting between the wolf native keys and signatures and the formats
documented in this RFC?

Go to forum: wolfCrypt

3 Reply by pbreed

(2 replies, posted in wolfSSL)

Yeah I figured it out.. was set to single threaded....
Fixed that...

Go to forum: wolfSSL

4 Topic by pbreed

(2 replies, posted in wolfSSL)

The documents for WolfSSL say that once its created the CTX is thread safe and
that activities on individual wolfssl connections/objects  need to be protected from access by multiple threads.


I implemented this and the internal SSL objects are showing signs of corruption.
(example FreeZero is being called with huge negative sizes)

IF I put a single global critical section around all ssl connection instances everything the problem goes away.

Thoughts Ideas?

Go to forum: wolfSSL

5 Reply by pbreed

(4 replies, posted in wolfSSL)

Can I change the behavior in wolfSSL_write by limiting the writes to some maximum that guarantees it fits in one encrypted block?

If so then I can manage outside the wolfSSL code to block/unblock writes into the system if TCP can't accept a full encrypted block of data...

Go to forum: wolfSSL

6 Reply by pbreed

(4 replies, posted in wolfSSL)

I'm CTO of Netburner. (Also original author of NetBurners written from scratch SSL/TLS)
We are porting to use WolfSSL...
(Why are we porting? because we found that keeping up with the evolution of TLS standards and ciphers etc.. was more work than the internal economic value it was creating. So we tried to solve this by porting to XXXXSSL.
Then almost immediately hit the wall with features we needed not supported by XXXX....
So we are trying again to use an external library (wolfSSL in this case) with the goal of not having a full time engineer work on nothing but TLS.



The reason for my question is almost perfectly encapsulated in the forum comments I posted in my initial request...
https://www.wolfssl.com/forums/topic393 … ocket.html


Basically we a TCP system that can generate notification of new data, and write buffer changing from block to unblocked...

I also have customer written code that operates on an FD  that needs all of the select (read,write,error) functionality...

I need to connect the two realms without creating a very expensive task for each SSL connection....


So TCP tells me there is new data available to read on the TCP socket associated with the WolfSSL connection...
I give that data to the wolfSSL system and as a result of that data I might or might not have generated decoded data for the customer/user code to read. So until that TCP data is processed I don't know if I can tell the customer/user FD if there is data avail , an  error or whatever...

One grossly inefficient way to do this would be to start a task/thread for each connection...
I'm looking for how I can multiplex each of these TCP notifications saying read data is available in a single SSL managment thread to marshal data from TCP throught the WolfSSL to/from the customer/user connections.

Both the XXXXSSL and NetBurners internally written TLS  code we are porting away from had that capability nativity.

I also need to extend the concept from just the read channel to write and accept and connect so the whole system can run asynchronously.

If I can't make this mode of operation work then I will have to seek other solutions, as the alternative is to tell 10K customers they must rewrite their code...

I've looked at the example pointed to in your previous response  and it seems like it only manages a single connection asyncronously, and does not do an asynchronous accept....

I've spent close to a week digging in your code and I think the solution I outlined above will work...
We are in the middle of experimenting in this space....

I do have one specific question I don't exactly understand...

lets say I call wolfSSL_write  with  data to write...so much data its going to need to be in multiple TLS messages...

There are three possible outcomes...
1)wolfSSL_write is able to encrypt the all of the requested write data into a block and ship ALL of that data out via TCP.

2)wolfSSL_write is able to encrypt the all of the requested write data into a block and ship SOME  of that data out via TCP.
with subsequent writes to the TCP system returning would block...

3)wolfSSL_write is able to encrypt some of the requested write data into a block and ship SOME  of that data out via TCP.
with subsequent writes to the TCP system returning would block...

 
So operating in an asynchronous manner in case 1, I'd expect the wolfSSL_write function to return the number of bytes written, matching the number requested...

In 2,3 I'd expect an error of
SSL_ERROR_WANT_WRITE

, but 2,3 are DIFFERNT!

How do I tell the difference between case 2 and case 3....
When I later get notified that the TCP connection has cleared its write backlog....
how do I recover for case 2 and case 3...

This is especially problematic when the write request will span multiple TLS encrypted data blocks...

Go to forum: wolfSSL

7 Topic by pbreed

(4 replies, posted in wolfSSL)

Looking through the code I see no interface for asynchronous reads.
IE asynchronously pushing data into the SSL connection.
(see this earlier unresolved thread on this forum
:https://www.wolfssl.com/forums/topic393-using-wolfssl-embedded-ssl-with-an-asynchronous-socket.html)


Using your interface as is will the following work:

It seems to imply that the asynchronous accept/connect calls will fail if the read returns would block, but to keep calling the accept or the connect until it does succeed.

It also seems to suggest that the wolfSSL_peek will cause a read too occur...

So my strategy would be the following:

If I get asynchronous notification of new data to be read from tcp into the SSL connection:

If the connection is still trying to connect or accept, call the appropriate connect/accept until that function succeeds.
If the connection has finished the accept/connect negotiation then call peak instead.

This should work and can be multiplexed across multiple SSL connections inside a single SSL worker thread.

Does this sound like the correct strategy?

Go to forum: wolfSSL