You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by Kaleb J. Himes
kjjy7,
Please share what it is you are working on. Thanks.
- K
@Pal,
I checked our roadmap and we do not have this feature listed. I am putting in this feature request on behalf of this forum post
Feature Requested: "AES-GCM support for processing data chunks without buffering entire input"
Requestor By: @pal, @yaroslav.torzuk
Requestor Email: <left out for public forum post>
Requested Source: wolfSSL Forums
Source Link: https://www.wolfssl.com/forums/topic1266-aesgcm-stream-encryption.html
Requested Date: 26 Sep 2018
Request Priority: 2 users requested to date, non-funded effort
Implementation Timeline: None
Special Notes: None at this timeWarm Regards,
- K
@Crypto,
Are you including <wolfssl/option.h> in your application? If the debug messages are not printing that indicates the application is not pulling in the configured settings. If you are including options.h and the debug messages are not printing could you double check what is in options.h and make sure the settings reflect the configuration used?
- K
@pal,
Thank you so much for clarifying! It is much clearer now what the end goal and use-case is! I will check our road map to see if we have something like this planned for the future similar to the CBC solution we implemented. If it is not yet on our road map I will add it to our feature request list!
Feature request are unfunded projects that we work on if we have free time but they can always be accelerated via a working agreement if there is a time-line to consider!
Warm Regards,
K
Yaroslav,
I see. Reducing the footprint is good but using AES-GCM in this fashion could result in massive run-time resource use depending on the data being encrypted. Because AES-GCM uses an authentication step if you want to use it as a stream cipher you would have to pre-load the entire input so it could be authenticated once the encryption was complete. Do you control the size of the items being encrypted? Are they always of a fixed, and finite size or can they be items such as a video file on the order of gigabytes large?
There have been some stream-like implementations of AES-GCM done against other crypto libraries and it is not impossible. It is also not very practical in most use cases due to the authentication step in AES-GCM. If however this is something you would like to see support added for in wolfSSL I am happy to bring it up with the wolfSSL team to gather their thoughts and input as well. Let me know if this is something you wish for us to consider with understanding that it is not run-time resource friendly.
- K
Hi Yaroslav,
Can you tell us about what it is you are working on and what motivated the need to attempt to use AesGCM as a stream cipher? The reason I inquire is that GCM already has significant throughput over a chained-block-cipher like CBC as it's blocks can be encrypted in parallel and do not suffer the same performance and efficiency impacts as a chained block cipher would. The reason for supporting CBC stream modes is to offer a more performant solution.
Due to the authentication step in GCM I am not entirely sure it would make sense to try and use GCM in this way unless you could guarantee all inputs would be reasonably small to avoid massive memory use. Have you considered AES-CCM as an alternative?
If you are looking to optimize performance and throughput we do offer the --enable-aesgcm=table option.
If you can tell us a little more about your motivation and goals perhaps it would help us to better understand your need!
Warm Regards,
K
UPDATE:
Currently wolfSSL embedded SSL doesn't have the ability to generate a CSR. We have had a few inquiries recently about CSR generation though. Are you able to share any details about the project you are working on?
wolfSSL has CSR support and our manual is in the process of being updated! The new section will follow section 7.8 in chapter 7 of the wolfSSL manual which talks about Certificate Generation in wolfSSL. Please find the first content draft below:
7.9 Certificate Signing Request (CSR) Generation
wolfSSL supports X.509 v3 certificate signing request (CSR) generation. CSR generation is off by default but can be turned on during the ./configure process with:--enable-certreq --enable-certgen
or by defining WOLFSSL_CERT_GEN and WOLFSSL_CERT_REQ in Windows or non-standard environments.
Before a CSR can be generated the user needs to provide information about the subject of the certificate. This information is contained in a structure from wolfssl/wolfcrypt/asn_public.h named Cert:
For details on the Cert and CertName structures please reference section “7.8 Certificate Generation” above.
Before filling in the subject information an initialization function needs to be called like this:
Cert request;
InitCert(&request);InitCert() sets defaults for some of the variables including setting the version to 3 (0x02), the serial number to 0 (randomly generated), the sigType to CTC_SHAwRSA, the daysValid to 500, and selfSigned to 1 (TRUE). Supported signature types include:
CTC_SHAwDSA
CTC_MD2wRSA
CTC_MD5wRSA
CTC_SHAwRSA
CTC_SHAwECDSA
CTC_SHA256wRSA
CTC_SHA256wECDSA
CTC_SHA384wRSA
CTC_SHA384wECDSA
CTC_SHA512wRSA
CTC_SHA512wECDSANow the user can initialize the subject information like this example from https://github.com/wolfSSL/wolfssl-exam … example.c:
strncpy(req.subject.country, "US", CTC_NAME_SIZE);
strncpy(req.subject.state, "OR", CTC_NAME_SIZE);
strncpy(req.subject.locality, "Portland", CTC_NAME_SIZE);
strncpy(req.subject.org, "wolfSSL", CTC_NAME_SIZE);
strncpy(req.subject.unit, "Development", CTC_NAME_SIZE);
strncpy(req.subject.commonName, "www.wolfssl.com", CTC_NAME_SIZE);
strncpy(req.subject.email, "info@wolfssl.com", CTC_NAME_SIZE);Then, a valid signed CSR can be generated using the variable key from the above key generation example (of course any valid ECC/RSA key or RNG can be used):
byte der[4096]; /* Store request in der format once made */
ret = wc_MakeCertReq(&request, der, sizeof(der), NULL, &key);
/* check ret value for error handling, <= 0 indicates a failure */Next you will want to sign your request making it valid, use the rng variable from the above key generation example. (of course any valid ECC/RSA key or RNG can be used)
derSz = ret;
req.sigType = CTC_SHA256wECDSA;
ret = wc_SignCert(request.bodySz, request.sigType, der, sizeof(der), NULL, &key, &rng);
/* check ret value for error handling, <= 0 indicates a failure */Lastly it is time to convert the CSR to PEM format for sending to a CA authority to use in issueing a certificate:
ret = wc_DerToPem(der, derSz, pem, sizeof(pem), CERTREQ_TYPE);
/* check ret value for error handling, <= 0 indicates a failure */
printf("%s", pem); /* or write to a file */Limitations:
There are fields that are mandatory in a certificate that are excluded in a CSR. There are other fields in a CSR that are also deemed “optional” that are otherwise mandatory when in a certificate. Because of this the wolfSSL certificate parsing engine, which strictly checks all certificate fields AND considers all fields mandatory, does not support consuming a CSR at this time. Therefore while CSR generation AND certificate generation from scratch are supported, wolfSSL does not support certificate generation FROM a CSR. Passing in a CSR to the wolfSSL parsing engine will return a failure at this time. Check back for updates once we support consuming a CSR for use in certificate generation!See also:
7.8 Certificate Generation
Hi mehendra,
Thanks for contacting us about this. From the wolfSSL main library root directory IE wolfssl-3.15.3/ browse to IDE/MDK5-ARM/Projects. We would recommend that you use those projects as your base and then layer in wolfMQTT once you have the SSL/TLS and Crypto parts building and working properly. Use the wolfssl-3.15.3/IDE/MDK5-ARM/Projects/CryptTest project to test crypto is working properly before moving on to SSL/TLS and ultimately MQTT testing!
To enable support for FreeRTOS uncomment the define FREERTOS in wolfssl-3.15.3/wolfssl/wolfcrypt/settings.h
Please let us know if you have any additional questions.
Warmest Regards,
K
zeta,
No this is not delicate information but it is non-standard/non-general and something we would have to handle via our consulting department. We are happy to answer questions of a "how-to", "break-fix", or "optimization" nature but your question requires a much more in-depth explanation. You are correct it is all open source and you can readily use our implementation as a reference if you do not wish to engage our consulting team.
Is there a reason you are trying to write your own TLS library rather than using the embedded-conscious wolfSSL TLS library we have spent years working on already? What is it about the wolfSSL TLS sources are not suitable for your needs? If we can understand your use-case and goals perhaps there is something we could do better in future development. We are always looking to improve so let us know where our library is falling short for you.
Warm Regards,
Kaleb
Update:
wolfSSL has support for all the notes from @rhoerbe and more:
ASN_PARSE_E = -140, /* ASN parsing error, invalid input */
ASN_VERSION_E = -141, /* ASN version error, invalid number */
ASN_GETINT_E = -142, /* ASN get big int error, invalid data */
ASN_RSA_KEY_E = -143, /* ASN key init error, invalid input */
ASN_OBJECT_ID_E = -144, /* ASN object id error, invalid id */
ASN_TAG_NULL_E = -145, /* ASN tag error, not null */
ASN_EXPECT_0_E = -146, /* ASN expect error, not zero */
ASN_BITSTR_E = -147, /* ASN bit string error, wrong id */
ASN_UNKNOWN_OID_E = -148, /* ASN oid error, unknown sum id */
ASN_DATE_SZ_E = -149, /* ASN date error, bad size */
ASN_BEFORE_DATE_E = -150, /* ASN date error, current date before */
ASN_AFTER_DATE_E = -151, /* ASN date error, current date after */
ASN_SIG_OID_E = -152, /* ASN signature error, mismatched oid */
ASN_TIME_E = -153, /* ASN time error, unknown time type */
ASN_INPUT_E = -154, /* ASN input error, not enough data */
ASN_SIG_CONFIRM_E = -155, /* ASN sig error, confirm failure */
ASN_SIG_HASH_E = -156, /* ASN sig error, unsupported hash type */
ASN_SIG_KEY_E = -157, /* ASN sig error, unsupported key type */
ASN_DH_KEY_E = -158, /* ASN key init error, invalid input */
ASN_NTRU_KEY_E = -159, /* ASN ntru key decode error, invalid input */
ASN_CRIT_EXT_E = -160, /* ASN unsupported critical extension */
ASN_ALT_NAME_E = -161, /* ASN alternate name error */
ASN_NO_PEM_HEADER = -162, /* ASN no PEM header found */To view other ASN error types see our error header here: https://github.com/wolfSSL/wolfssl/blob … or-crypt.h
jskier,
Let us know if you have any further issues!
- K
Bitgid,
wolfSSL does not support that cipher suite, the options that are similar and supported are:
ECDH-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
Is it possible you meant one of those cipher suites instead?
Regards,
K
Hi zeta,
Thank you for using the wolfSSL forums. Can you tell us what it is you are working on and what the purpose is for inquiring about the sequence number, how to count it and whether or not the IV is contained therein? This is not a typical thing users are asking for so it would be good to understand the motivation behind the question. Looking forward to more details!
Warm Regards,
K
kjjy7,
Have you looked into padding schemes? Why is the key string only 4 bytes, what is preventing you from creating a 16-byte key string?
Regards,
K
Hi ePaul,
Thank you for using the wolfSSL forums! We very much appreciate hearing how and why users are evaluating/testing with wolfSSL, can you tell us a little about what you do and the current project you are working on?
We have an example of programmatically generating a CSR in wolfSSL if you look at the test application <wolfssl-root>/wolfcrypt/test/test.c
The function rsa_certgen_test is a good place to start. Then notice when we copy in the certDefaultName that if WOLFSSL_MULTI_ATTRIB is defined we provide up to 4 additional attributes that users can specify. See function "initDefaultName" which we call earlier on in the tests. In that function check the section guarded by macro WOLFSSL_TEST_CERT (also depends on WOLFSSL_MULTI_ATTRIB being defined). Then you'll see a section guarded by "#if CTC_MAX_ATTRIB > 3" These are the user-configurable attributes.
Please let me know if you have any questions while getting your extra attribute setup!
Example based on the link you sent:
NameAttrib* n;
n = &certDefaultName.name[0];
n->id = ASN_SERIAL_NUMBER;
n->type = CTC_PRINTABLE;
n->sz = sizeof("1801908070");
XMEMCPY(n->value, "1801908070", sizeof("1801908070"));Warm Regards,
Kaleb
Hi JC,
Thank you for the details. I am not seeing anything extremely obvious but I am curious what error occurred prior to ASN_NO_SIGNER_E lower in the crypto library. Could you try two things and let me know the results:
1) Could you compile and run the application: <wolfssl-root>/wolfcrypt/test/test.c to confirm all the crypto is running properly on your device.
2) Once you have confirmed the crypto is working (if it is) could you add the define DEBUG_WOLFSSL to your settings and make the connection again. Can you send us the resulting log from the failed connection for review?
Warm Regards,
Kaleb
Hi Elyhance,
Did you ever get a chance to test a cert that was approved as a signing authority? What were your results?
Pilatuz,
Hi Kaleb, thank you for your reply.
As you noted,the root certificate authority MAY be omitted from the chain
"MAY" assumes that both options are valid whatever server sends root certificate or not.
And it's not clear why verification works if both root+intermediate provided?
It seems that this issue is related to "Key Usage" TLS extension as noted here https://security.stackexchange.com/ques … rtificates
For the another server with "Key Usage" TLS extension enabled the root certificate only if enough to verify.
Correct! "MAY" indicating the ROOT CA may be omitted since the client presumably already has a copy loaded to validate the peer. This in no way implies an INTERMEDIATE CA may be omitted. Clients know about ROOT CA's, they do not always know, nor can they be expected to know about intermediate CA's. Conforming servers should not omit any cert from the chain except the root ca but like I mentioned not every server is a "conforming" server unfortunately.
Apologies for the delayed response on this one. The reason you had to provide both intermediate CA and root CA for verification to work is that wolfSSL checks the signatures and rebuilds the entire chain of trust. If a cert chain is composed of the certs A, B, C, and D let's say and the server only sends C and D during the handshake and wolfSSL side has only loaded A your chain is this:
A -> [MISSING] -> C-> DwolfSSL will never validate this chain and it has nothing to do with the "Key Usage" extension.
In your case this is exactly what happened. wolfSSL did not have all the certs necessary to build the entire chain of trust so validation of the chain failed and the connection did not proceed. Once you loaded both A and B on the wolfSSL side and wolfSSL received cert C during the handshake it was able to rebuild the entire chain of trust and validate the authenticity of the peer.
Regards,
Kaleb
Pilatuz,
Your solution is the correct one. Turn on "Server Name Indication" extension by defining HAVE_SNI or by configuring with --enable-sni. Then from your application call:
int ret = -1;
char error_buf[WOLFSSL_MAX_ERROR_SZ];
char* hostName = "<The host name of the target server>"; // Example: "google.com"
if ( (ret = wolfSSL_CTX_UseSNI(ctx, WOLFSSL_SNI_HOST_NAME, hostName, XSTRLEN(hostName))) != WOLFSSL_SUCCESS) {
printf("Setting host name failed with error condition: %d and reason %s\n", ret, wolfSSL_ERR_error_string(ret, error_buf));
}- Kaleb
SamSam,
It was our pleasure! Thanks for sharing the project details, that is very exciting to see! Thank you also for using the wolfSSL forums to address your issue. If anything else comes up in the future please reach out to us anytime, you can use the public forums here or you can shoot us an email at support@wolfssl.com for quicker response times!
Cheers,
Kaleb
@jskier,
Thank you for your questions and for using the wolfSSL forums. I've reached out to our TLS 1.3 expert to see if he has any thoughts.
I'll let you know what I find. In the meantime could you tell us a little about your project with NGINX and interest in using the wolfSSL solution?! We love to hear what it is our consumers are working on and what motivated the effort. Thanks!
- Kaleb
Hi SamSam,
wolfSSL targets a release every 3 months. Our last release was on June 20th of 2018 so our next target date would be sometime around Sep 20th give or take. We do not have a hard release date at this time but it could be anytime between now and the beginning of October.
Do you have any timelines you are facing and if so can you share what your timelines are and what is driving the effort on your side?
Warm Regards,
Kaleb
Hi kjjy7,
You should always include options.h before any other wolfSSL header. That being said you should never include internal.h as you will encounter issues with forward declarations. We define the same structs in internal.h and ssl.h You can not use ssl.h and internal.h together and you can not use most functionality in wolfSSL without ssl.h. The design is intentional. API's in internal.h are not for use by external applications for security reasons.
Can you still not share what it is you are working on?
- Kaleb
@SamSam,
Just letting you know I have asked @embhorn to take a look at your report as a possible maintenance item. He is reviewing and will post an update when he has a solution.
- Kaleb
Osiris,
Thanks for asking! To ensure this API is available please build with the setting "#define KEEP_PEER_CERT" or if using auto tools and configure:
./configure CFLAGS="-DKEEP_PEER_CERT"Warm Regards,
wolfSSL - Embedded SSL Library → Posts by Kaleb J. Himes
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.031 seconds (65% PHP - 35% DB) with 4 queries