wolfssl
wolfssl copied to clipboard
wolfSSL
Added support for P384 pre-share in server
Description
EEMBC has been doing testing with various SSL server implementations for P256, P384 and 25519. We added this switch, and thought it would be easier for our users if it was in the wolf repo instead of us having to supply a diff patch.
Testing
I simply ran:
% cd examples/server
% ./server -v 4 -E &
% cd ../client
% ./client -v 4
Checklist
- [ ] added tests
- [ ] updated/added doxygen
- [ ] updated appropriate READMEs
- [ ] Updated manual and documentation
Since this is an example, there were no tests (AFAIK), doxygen, or READMEs. However, I did update the help screen (took a guess at the Japanese.)
@dgarske,
Will do. Would you have a problem with an implementation that supported --use-curve <curve> so that in the future it would support basically any curve?
--Peter
@dgarske,
Will do. Would you have a problem with an implementation that supported
--use-curve <curve>so that in the future it would support basically any curve?--Peter
Go for it! Sounds good to me.
Hello @dgarske,
I modified the code to use --force-curve. It scans the ecc_sets[] and compares what is compiled in that array to the WOLFSSL_ECC_* group codes (by strcmp!), then attempts to set the single group.
While testing, I found that after compiling in the Koblitz, Brainpool, V2, and V3 curves, I could force the group OK, but the client couldn't connect to any of these. Still debugging this, but if you have an idea lemme know.
Otherwise it works fine, although it is a mutex with -y, -Y, and -t (might need to add a warning?)
Peter
Sorry for the extra spam, misread the diff log on the '-E' argument colon. Fixed the shadow variable error from testing.
Is there any way I can run all of the workflows locally to avoid waiting for GitHub to alert me to errors?
Is there any way I can run all of the workflows locally to avoid waiting for GitHub to alert me to errors?
When you push to a branch (with different name) in your fork it will run the GitHub Action CI.
@petertorelli you are now an approved contributor. I am doing a squash merge. Thanks again. If you can share links to your work using wolfSSL at the eembc that would be wonderful. Thanks, David Garske, wolfSSL
@dgarske Thanks for the great support! I'll drop a link in this PR and tag you once we stick a license on the repo that contains our tracing code and make it public.
@dgarske Here is a link:
https://github.com/eembc/sec-trace
It is a tracing tool we use for examining how many cryptoprimitive calls are made during each pipestage of the TLS handshake, and how much data they require. It is for a benchmark development and analysis. Planning on doing a whitepaper for ArmCon this year.
@dgarske Here is a link:
https://github.com/eembc/sec-trace
It is a tracing tool we use for examining how many cryptoprimitive calls are made during each pipestage of the TLS handshake, and how much data they require. It is for a benchmark development and analysis. Planning on doing a whitepaper for ArmCon this year.
Hi @petertorelli , thank you for sharing! That's wonderful work!
Note: We have many build options for improving the ECC performance. For example if you add --enable-sp --enable-sp-asm --enable-intelasm. See out math options: https://www.wolfssl.com/documentation/manuals/wolfssl/chapter02.html#wolfssls-math-options
Specifically enabling the SP math assembly speedups.
If you need help figuring out how to enable those with CMake let me know.
@dgarske Thanks for the info. I had been working with Jacob B. for publishing wolf scores and he helped me optimize the library. This analysis doesn't care about performance, it is just to understand "how much" crypto computation is required by different TLS libraries. In order to benchmark a "typical use" case, we need to analyze popular TLS libraries.