You are not logged in. Please login or register.
Active topics Unanswered topics
Welcome to the wolfSSL Forums!
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
References
Stable Releases - download stable product releases.
Development Branch - latest development branch on GitHub.
wolfSSL Manual - wolfSSL (formerly CyaSSL) product manual and API reference.
Search options
sadly i'm running 1.8 because I've made serious modifications to get cyassl embedded SSL running in a non-standard environment. I want to get 1.8 ported and running, then update to 2.0. Mainly because of those pesky deadlines 
Can you describe what the error is intended to mean? Looking at 2.0 source it gives a little more clarrification from this line of code
CYASSL_MSG("No CA signer to verify with");
I am running cyassl as a client. Maybe I missed a step of loading a CA. My code is loading one cert as the CA cert during the CyaSSL_CTX_load_verify_buffer(). Is it possible my CA PEM is incomplete?
My CA loading code:
CyaSSL_CTX_load_verify_buffer(ctx, caCertBuffer, caCertBufferSize, SSL_FILETYPE_PEM)
Maybe I am fundamentally doing something wrong. Any insight?
update. I created a new certificate and key (the previous cert had been generated by a co-worker). I got past the previous problem.
I now get an error of ASN_SIG_CONFIRM_E (-155).
are there tools that can verify a certificate is valid and void of any errors?
during the SSL handshake I am receiving this error.
error -144 ASN_OBJECT_ID_E /* invalid id */
it appears to throw the error in asn.c GetName().
Seen this before? any suggestions to troubleshoot?
aaaww, found it in examples. I screwed up on my grep skillz and thought it wasn't found.
ok, I see that too. But then SSL_connect() is returning a "SSL_FATAL_ERROR". I don't know if I consider a WANT_READ as a SSL_FATAL_ERROR. How do you recommend I distinguish from an error and a WANT_READ? Look at ssl->error upon return?
You can test this by defining NON_BLOCKING for the examples.
"NON_BLOCKING" is what I should define as a compiler flag? I don't see any of those in the code.
I understand your recommendation. SSL_connect() appears to only work with a blocking network model.
Loking in the source code at the SSL_connect(), I see all the case statements and a while loop to block for a response...but there are no "breaks;" to jump out of the switch statement and then out of the function.
Please enlighten me.
There are few paragraphs about the handshake callback. I have been digging in the code and docs but not sure how to use this feature. I have a network stack that runs on a callback. I also can't do any blocking while waiting for network data. How should I integrate with wolfSSL? Please advise Todd! 
i'm finally back to this portion of your embedded SSL code (network stack calls). I thought you should know that the flag "CYASSL_USER_IO" isn't mentioned anywhere on the site or in documentation. I had stumbled on it in the code...there maybe more questions coming
I noticed this is an option in ssl.c. What are the pro/cons of defining this flag?
If i'm not mistaken, CYASSL_USER_IO needs to be defined in non-standard environment. Will you please elaborate what I need to implement when defining this flag?
aah, we are using a very old GCC. Understandable why its confused.
my compiler doesn't like this syntax and i've never seen it before. is it ANSI C? the 'long long' part?
typedef unsigned long long ulong64
I've been porting tfm.c these days. I'm getting a compiler error on line 294.
typedef unsigned long long ulong64
if I remove one of the 'long' from that line it compiles but then I get a new warning
warning: right shift count >= width of type
which I assume is because the variable type is wrong (not big enough)
please enlighten me todd
todd, can you tell me what cipher suits(s) you had compiled for the mbed port to get the 63kB? I'm still working to get everything compiled so I don't know what size the library will be. I'm trying to get a general idea. I understand the size will vary and I plan to compress the binary. Can you tell me the largest size cipher options? It appears AES and Diffie-Hellman are the largest.
thanks Todd. you are correct on all accounts. Cipher suite is the following:
authentication: RSA
key-exchange: Diffie-Helman
bulk cipher: AES
MAC: SHA-256
L.S. said:
However, it can be built smaller if you cut out some of the ciphers. Some
guys on the OpenWRT project managed to build CyaSSL [wolfSSL] to around 15k.
The wolfSSL code is very compact and organized very well. As you said, to reduce size I'm stripping out ciphers. The problem lies in dependencies. While I am continuing my effort to discover the dependencies, I am hoping you can give some insights. I am trying to build the smallest embedded SSL library possible and only will be using these three features: AES, Diffie-Hellman, SHA-256. In essence my SSL library will support only one stream cipher: AES. The supported client will be built the same.
These are the source files I think I need:
tls.c
ssl.c
aes.c
dh.c
sha256.c
integer.c
random.c
misc.c
Questions:
asm.c - this is assembly for x86 optimization?
So far it appears that integer.o is 50k!?? So I assume adding DH is costly?
I would appreciate any insights.
excellent! thanks for the clarification
In version 1.8 it looks like the purpose of you renaming the /ctaocrypt/include/ files to "ctc_xxxx.h" (ctc_aes.h) is so that we can now copy all the .h files into the same folder? we no longer need a ../openssl folder when building on non-standard environment?
I am in the process of porting wolfssl embedded SSL to an embedded device without a standard environment. I followed the documentation to put all the files in one directory. Also ../openssl was created and populated with .h files.
In "tls.c" there is a line of code #include "ssl.h" ssl.h cannot be found in the current path and after looking at all the source code it can be found in ../openssl/ssl.h . I can add this as an include in the build path.
I mention this because the directions specifically say to put openssl header files in the parent path so I expected that the source would be looking for "../openssl/ssl.h" and the other .h files.
ok, so your RTOS is providing the network stack? my environment is different so we have ported our own network stack. I was hoping you had one to suggest as we are seeing problems with our stack. Know any C open source network stacks that you would recommend?
Your mbed port is a GREAT example of what is possible with CyaSSL!!!
A co-worker is working on porting a network stack to our embedded device. I was hoping you could share what network stack you chose for the mbed port. From reading your blog I assume µC/TCP-IP...correct?
I saw the blog post regarding some of the performance metrics for cyassl on mbed. Will you share what you had enabled (block cipher, hash, key exchange) for your mbed build. Have any other performance observations to share? Since you are the expert i'm curious. As of right now i'm planning to only support AES, MD5 and RSA. I need to be as small and efficient as possible but of course also keep a certain level of privacy.
Posts found: 22
Generated in 0.017 seconds (94% PHP - 6% DB) with 4 queries