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 ctb
Pages 1
Gotcha, Chris.
However, using this in a keywrap is still part of the DNP Secure Authentication v5 protocol, so I have to go ahead and implement it. I think it does make it a bit more secure because the keywrap function actually used previous values to generate the IV for the next AES operation.
I dug into the code a bit and found AesEncryptDirect(...);
The only thing is that I had to enable the precomplier switch for WOLFSSL_AES_DIRECT.
Also, the functions seem to be a bit outdated because they were returning the return value from a function that returned void, in a function that returns void.
I simply removed the return in the function and everything compiles correctly and I got the right value from the AES encryption. So, problem solved. I think. Unless there is some issue with me using these direct functions. They aren't in the documentation but it appears it is just a direct call to the base AES function itself, which is used in the code, so I suspect it is fine.
I am trying to implement the key wrap AES Key Wrap Specification described in csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf
I am just trying to get the "encrypt" part to work right now with wolfSSL embedded SSL, and am using the "alternate algorithm."
The key wrap algorithm contains multiple AES encrypting iterations. The document gives you known values for the example inputs (located at the end of the document), but I am having no success getting it to work for the first iteration.
In the key wrap document, they say:
B = AES K (A | Ri )
Which is basically saying do an AES encryption with key K on the concatenated data, A (the initialization vector) and the i-th 64 bit data block of the data. So for the first iteration, the i-th data would be the first 64 bits of the data to be wrapped. And then put the encrypted data in B.
I see when I call AesSetKey(...) I am passing it the Initialize Vector (A). And when I call Aes...Encrypt(...) I do not pass it the IV.
Does the code automatically concatenate the IV onto the beginning of the data when you call Aes...Encrypt(...)? Or do I still need to handle that concatenation myself? If the latter, how does the IV get used in Aes...Encrypt(...)?
Also, I'm not sure which Aes...Encrypt(...) to use (CBC, CTR, GCM, etc) for this. It says "codebook" which is another kind you apparently don't support, but it also say it isn't a good one to use on the wikipedia page.
Thanks
Looks like the problem still exists in this version of the usage reference.
First, thanks for the help so far. To follow up on this, I think there is some kind of error in the documentation. I just want to clarify that I am doing this right.
I am using:
wolfSSL User Manual
March 11, 2013
Version 2.5.1
On page 79/80 under the section: 10.5.4 DSA (Digital Signature Algorithm)
In the example, there is no "tmp" variable defined. However, it is used.
Looking at the function call:
ShaUpdate(&sha, tmp, message);
I'm pretty sure is wrong, as you are passing message, which is byte *, to the word32 length part of the function.
I assume that the tmp variable should be gotten rid of, and replaced with message. And the function call should look like
ShaUpdate(&sha, message, sizeof(message));
And then this would propagate down to:
DsaPrivateKeyDecode(message, &idx, &key, dsaKeyBuffer);
Am I correct?
I would suspect that I have to only use the cryptography library.
However, I suspect it is just a subset of the larger wolfSSL library. The IDE I am using does a lot of dead stripping so is it okay for me to continue using the wolfSSL library, or do you still recommend that I use the wolfCrypt. When we were discussing licensing, we were referencing the WolfCrypt, and when I got the code, I thought maybe it was just a subset of what I have. If you think I should switch, now would be a good time as I have not done too much, but I would need to source.
I am reading the other sections now, thank you.
Charlie
I would probably benefit from this as well. So if you could send it to me too, Chris, that would be great.
Forgive me if I sound like an idiot. All of this cryptography stuff is very new to me and I am trying to struggle my way to understanding it all and getting this to work.
To give a brief background of my project, I am implementing the DNP3.0 protocol which contains Secure Authentication (SA). I am using a 3rd party software that handles the bulk of the protocol, but I am using wolfSSL embedded SSL to implement the cryptography part. So basically I am bridging the calls from the other software to wolfSSL.
The first place I seem to have gotten stuck is verifying a signature. The section of the wolfSSL Manual that deals with this is, I think, 10.5.4.
To make it simple, let's just assume that they are only using the SHA256 hashing algorithm to verify the signature. I'm not even sure I will implement the SHA1 part because it appears to not be recommended any more.
So I am being passed a pointer to an array of bytes that contains the key (*pKey) and its length (pKeyLength). Also I am being passed a pointer to an array of bytes that contains "data to use for verifying signature" (*pData) and its length (pDataLength). The last thing I am being passed is "signature data (certification) to be verified" (*pSig) and its length (pSigLength).
I am having a hard time understanding how I fit this into your functions. I have dug down into some of the structures and functions, but it wasn't clear to me exactly how I should tie this data in. I don't think I need to call "InitSha256()" or do any of the updating or Final. . . but I'm really not quite sure. I assume I only need to figure out how to get their data/key into your data/key and then call DsaVerify, but I can't find the information I need to make this happen.
Thanks for any help.
Pages 1
wolfSSL - Embedded SSL Library → Posts by ctb
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.016 seconds (96% PHP - 4% DB) with 4 queries