The most common reasons for this is:

1) The signature has the ASN.1 encoding. See WC_SIGNATURE_TYPE_RSA_W_ENC, wc_SignatureDerEncode or wc_EncodeSignature.

Can you share a snippet of the code you are using?

Thanks,

David Garske, wolfSSL

Thank you very much

This example will be very helpful for me.

Please close this topic.

]]>I just opened the pull request which you are free to reference. I'm just waiting for a peer review to merge it into our examples master repo.

https://github.com/wolfSSL/wolfssl-examples/pull/80

Warmest Regards,

Kaleb

]]>Perfect! Thank you very much.

I am waiting for your example, please share the github address when you finish it.

]]>I see! Since the input will always be a fixed length (AES KEY SIZE). Then what you are asking for is entirely possible with wolfSSL. The API name may be misleading but if you were to use:

wc_RsaSSL_Sign = RsaPrivateEncrypt without hashing, just padding.

Then on the other end:

wc_RsaSSL_Verify = RsaPublicDecrypt without hash, will do the un-pad for you.

In this way you could use RsaSSL_Sign to encrypt the AES key and RsaSSL_Verify to decrypt the aes key when it arrives on the target device for firmware update.

Due to this question I am working on an example that I will try to get up on github soon. I will push it to here: https://github.com/wolfssl/wolfssl-examples.git

Let me know if you have any questions on that!

Warmest Regards,

Kaleb

]]>Thanks for your explaination.

The background and requriement is :

Normally, when we release the upgrade package for any product, the integration team will use RSA private key to generate signature for upgrade package, then the final upgrade package will include both original package data and its signature file.

When the product need to do upgrade, the product's firmwair will use paired RSA public key to do signature verify for ensure the upgrade package is authenticate. This is the normal upgrade process. (Note, the product's firmwair doesn't include RSA private key, only have RSA public key. The RSA private key also hold by integration team or our customer)

But, now we met trouble, our product is tampered by some hackers. Why hackers can understand our product? Because they received our uprade package through some way, and done '**reverse engineering**' on our uprade package. Because our upgrade pakcage is plain text, even it include signature.

So, I want to let upgrade pacakge always showing cipher text, in this situation, hacker is impossible to do '**reverse engineering**'.

My propoal is : during every integration time,

1st, integration team will generate one AES128 key randomly, and use AES128 key to encrypt the original upgrade package as cipher text;

2nd, this AES128 key will be encrypted by RSA private key

3rd, use RSA private key to generate signature for original upgrade package.

4th, finally, the real upgrade package will icnlude -> cipher file of AES128 key + cipher file of original upgrade package + signature file of original upgrade package

Then, the product's firmwire will decrypt and verify this upgrade package by RSA public key. In this proposal, we don't need store any more cipher keys in our product, only one RSA public key is enough. And I already used openSSL verified this proposal, it is possible.

Yes, maybe this is not a perfect solution, could you please give me better advice (based on wolfSSL library)?

]]>While possible due to the math, this is entirely impractical in practice. This functionality is not supported by wolfSSL so it is expected that you would not find API's such as "wc_RsaPrivateEncrypt" and "wc_RsaPublicDecrypt".

The reason we SIGN and do not ENCRYPT data with RSA is because we can first HASH the input to a fixed length and then pad it to the expected input length for the given RSA key size. The way the RSA algorithm works, your key must be as long as the data being encrypted so if you wanted to encrypt a file that was 1GB you would need to generate a 1 GigaByte RSA key!

Then if you wanted to encrypt the next item and it was 500KB you would need to generate a brand new RSA key that was only 500 KB long OR pad out your input file/data to 1GB in order to use your previously generate private key of 1GB.

You would end up in either a scenario with a ridiculous number of private/public key pairs that would need to be maintained in order to decrypt your data in the future OR if you failed to maintain those keys you would end up with a bunch of encrypted data that could never be decrypted.

If instead you SIGN the data by first hashing it to a fixed length and then padding to an expected length you can re-use the same RSA key pair for everything that needs SIGNED.

Can you explain what it is you are attempting to accomplish? Perhaps there is a better way to do it or a better algorithm to use for encrypting your data rather than RSA?

Warm Regards,

Kaleb

]]>RSA can encrypt up to the key size (2048 bits is 256 bytes), but it is not something you would normally use to encrypt larger amounts of data because of performance. Typically a key is secretly exchanged using DHE or ECDHE and that key is used as an encryption key for AES, 3DES or ChaCha20. This is what TLS handles automatically. Can you provide some more background to help us understand the situation?

The RSA functions are wc_RsaPublicEncrypt and wc_RsaPrivateDecrypt.

The ECC key agreement is wc_ecc_shared_secret.

The AES encrypt decrypt functions depend on the mode. AES CBC for example is: wc_AesCbcEncrypt and wc_AesCbcDecrypt.

If you are looking for something more lightweight to securely exchange messages you could look at our ECC encrypt example here:

https://github.com/wolfSSL/wolfssl-exam … aster/btle

Thanks,

David Garske, wolfSSL

I know, normally, we are using RSA public key to encrypt object data, then using paired RSA private key to decrypt the cipher data and retreive original object data.

But, based on RSA algorithm, it is possible to use RSA private key to encyrpt object data (not sign), then use paired RSA public key to decrypt the cipher data and retreive original object data.

I haven't found related wolfSSL APIs for this intention. Could you please give me some guide??

]]>