1 Topic by cxdinter

(1 replies, posted in wolfCrypt)

Hi,
   I know wolfSSL old version not support RSASSA-PSS padding signature, how about current situation?
   Many requirements become to request RSASSA-PSS padding for signatures, and forbid to use PKCS1_V1.5 padding.

Go to forum: wolfCrypt

2 Reply by cxdinter

(8 replies, posted in wolfCrypt)

Hi Kaleb,
  Thank you very much
  This example will be very helpful for me.

  Please close this topic.

Go to forum: wolfCrypt

3 Reply by cxdinter

(8 replies, posted in wolfCrypt)

Hi Kaleb,
  Perfect! Thank you very much.

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

Go to forum: wolfCrypt

4 Reply by cxdinter

(2 replies, posted in wolfCrypt)

Hi David,
  Thanks. I understood the situation.
  Please close this topic.

Go to forum: wolfCrypt

5 Topic by cxdinter

(2 replies, posted in wolfCrypt)

Hi,
   I am trying to use wc_AesCbcEncryptWithKey() and wc_AesCbcDecryptWithKey() for encrypt/decrypt data with AES128 CBC algorithm.

   The function wc_AesCbcDecryptWithKey() has no ouput parameter for decrypt data length. So, when the plain text length is not multiple of 16, how can I know the exact decrypt data length?
   I tried to use memset() for initialing decrypt buffer as all 0, then expect getting the exact decrypt length by strlen(). But I am failed. In decrypt buffer, after real plain text data, the padding are some abnormal data, not all 0.

  Could you please give me some guide? Thanks.

Go to forum: wolfCrypt

6 Reply by cxdinter

(8 replies, posted in wolfCrypt)

Hi 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)?

Go to forum: wolfCrypt

7 Topic by cxdinter

(8 replies, posted in wolfCrypt)

Hi,
  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??

Go to forum: wolfCrypt

8 Topic by cxdinter

(1 replies, posted in wolfSSL)

Hi,
    I found a difference between v3.9.10 and 3.11.0 :
    During TLS handshake procedure, if ASN_NO_SIGNER_E appear, the behavior of these two version are different.
   In v3.9.10,  TLS handshake will be ok finally.
   In v3.11.0,   TLS handshake will shutdown immediately.

   Why?
   Could you please explain, in which condition, this error will appear? TLS server request CA certificate in client certificate chain??

   The logic of  DoCertificate() function is totally different between these two version, currently, I can't fully understood them.

Go to forum: wolfSSL

9 Reply by cxdinter

(3 replies, posted in wolfSSL)

chrisc wrote:

Hi cxdinter,

This behavior was fixed starting with release 3.11.0 (released 5/4/2017), and is fixed in all subsequent versions.  Are you able to share what company/product you are working with?

Thanks,
Chris

Hi Chris,
    Thanks, I got it.
    Actually, we already baught commercial license from wolfSSL. And your collegue Rich also sent commercial version V3.11.0 to us. For this topic, I just used the old open source version for testing. We will not use open source version in production level release.

    Our company name is Yanfeng Visteon Electronics Technology (Shanghai) Co., Ltd.

    Please close this topic, thank you.

Go to forum: wolfSSL

10 Reply by cxdinter

(3 replies, posted in wolfSSL)

Sorry, I know the root cause. Becuase I defined NO_SESSION_CACHE macro in user_settings.h.

But there are still one problem : even I used NO_SESSION_CACHE, why the sever still send the old session ID during serverHello?? (I used an old wolfSSL version v3.9.10)

Go to forum: wolfSSL

11 Topic by cxdinter

(3 replies, posted in wolfSSL)

Hi,
   I used wolfSSL library to create a TLS server on our radio, then this server can communicate with one APP (allocated on a mobile phone ) through TLS1.2 . But, if user didn't operate APP for long time (maybe over 1 miniute), then operate APP again, the TLS communication will disconnect. Because client APP want to resume current SSL session ID, but server request full TLS  1.2 handshake process(request/send certificate..etc.) instead of sending ChangeCypher directly.

  I guess maybe the disconnect is caused by session timeout? is there any default value used to set as session timeout?
  And what's the difference between ssl->timeout and ssl->session->timeout ?

  Thank you in advance.

Go to forum: wolfSSL

12 Reply by cxdinter

(2 replies, posted in wolfCrypt)

Kaleb J. Himes wrote:

Hi cxdinter,

It has been awhile since we heard from you! December of 2016 I believe, how are things?

Anyway, I can see where the confusion might come in given the lack of "commentary" in that function. Since the output buffer being passed in is a pass by reference (pointer) we also need a way of controlling memory access beyond the call to this function. We accomplish that by setting outSz to the result length of the CMAC operation.

Typically we would expect a user to call

wc_AesCmacGenerate(out, outSz, in, inSz, key, keySz);

Now imagine the user did the following:

byte buf[4096] = {... some data ...};
int bufSz = sizeof(buf);
byte out[4096] = {0};
int outSz = sizeof(out);
byte key[KEY_LEN] = { .... some key ... };
int keySz = sizeof(key);
int ret;

ret = wc_AesCmacGenerate(out, outSz, in, inSz, key, keySz);
if (ret == 0)
    do something interesting with "out" based on outSz **ALERT**

If we did not adjust outSz to the fixed length of the resulting CmacFinal operation then the user would be accessing bad data, sure they would get their CMAC tag at the beginning of the buffer but they would be accessing 4096 - AES_BLOCK_SIZE data that they didn't need here. That is why we set it explicitly on exiting the function successfully.

    if (outSz != NULL)                                                           
         *outSz = AES_BLOCK_SIZE;

Also this sanity check protects against the case where the buffer being used is too small to store the result of the operation:

if (outSz != NULL && *outSz < AES_BLOCK_SIZE)
    return BUFFER_E;

Does that make sense? Let me know if you have any other questions on this.


Warm Regards,

Kaleb

Hi Kaleb,
    Nice meet you again:)

    Actually, I haven't left wolfSSL forum. Somtetimes, I will log in and learn from some topics.
    Now, our project are running with wolfSSL commercial version which ported by your collegue Garske, and your collegue Rich also visted our commpany in April. Now, we are partners.

   OK. back to this topic. I understood your scruple. But actually, If some user use so big buffer to store CMAC tag, that means he doesn't know what CMAC is, and he also doesn't know the relationship between AES algorithm and CMAC rule. If any project manager use these guys to develop security features, it is a tragedy.
   Anyway, stand on crypto library developer side, it's correct. We need to avoid any unexpect risk.

    Thank you. Please close this topic.

Go to forum: wolfCrypt

13 Topic by cxdinter

(2 replies, posted in wolfCrypt)

Hi,
   In this function, there is one judgment which list below:
   

if (outSz != NULL && *outSz < AES_BLOCK_SIZE)
        return BUFFER_E;

   Why here muse adjust *outSz  should great than AES_BLOCK_SIZE??
   Normally, if define one variable for store output CMAC size, and initialzie it as 0. then call this function, it will return FAIL ! (BUFFER_E)

  actually, at the end of this function, function will put real CMAC output szie to *outSz, so I can't understand why we need to adjust *outSz must great than AES_BLOCK_SIZE???
  maybe, the author want caller to assign a actual output CMAC size, but I don't think it is necessary. Because AES key size will decide the output CMAC size (like 128 or 256).

  what's your opion??

Go to forum: wolfCrypt

14 Reply by cxdinter

(3 replies, posted in wolfSSL)

Hi Kaleb,

I am fully understand your contradiction.
Because our product only can sync real data/time from car CAN network. But, during our development work, sometime, our product can't work in a real car environment. So, if we don't ignore the data/time exceed error, the TLS link will always fail.
Big appreciation for your solution, and I promise that I just use this solution for develop work, this change will not integrate into our product's formal software release.

At the end, merry Christmas for you!

Go to forum: wolfSSL

15 Topic by cxdinter

(3 replies, posted in wolfSSL)

Hi,
   In some scenarios, even the certificate already exceed the defined data/time, we still need trust it.
   So, is there any flexible way to disable/enable the verify for the data/time of certificate? I seems there are no one special macro used for this case.

   For details, how to let XVALIDATE_DATE(d, f, t) always return 1?

Go to forum: wolfSSL

16 Reply by cxdinter

(4 replies, posted in wolfSSL)

ASN.1 include several encode standards (Such as DER, BER, CER).
For certificate, mostly, people select DER as the encode standard. So, if your certificate is DER format, you should set the parameter as SSL_FILETYPE_ASN1.

PEM format is encoded by base64 algorithm based on ASN.1 format.

Suggest you read related ITU documents for X.690

Go to forum: wolfSSL

17 Reply by cxdinter

(8 replies, posted in wolfSSL)

Hi Kaleb,

I am fully understood.
Thank you very much.
This topic can be closed.

Go to forum: wolfSSL

18 Reply by cxdinter

(8 replies, posted in wolfSSL)

Hi Kaleb,

I understood now.
Thank you very much!

But there are two wolfSSL APIs which used for TCP connect. Both of them have the parameter 'port'. Why? (one is in io.c, another is in test.h)
I researched these two functions, like your description, the parameter 'port' seems not necessary.

static int tcp_connect(SOCKET_T* sockfd, const char* ip, word16 port)
static INLINE void tcp_connect(SOCKET_T* sockfd, const char* ip, word16 port,
                               int udp, int sctp, WOLFSSL* ssl)

Go to forum: wolfSSL

19 Reply by cxdinter

(8 replies, posted in wolfSSL)

Hi Kaleb,
    Sorry, based on your explanation, I think I have a wrong understanding with our product requirement.
    But how can server recognize current connect request is from which client? Could you please explain related mechanism?  I am not familiar with this situation.

Requirement: In order to enable standard HTTP communications over TLS on port 443 (and other https ports) and additional WebSocket communications over TLS on port 443 (and other wss ports) the client has to establish 2 HTTP/TLS connections and upgrade the second one to WebSocket. The client uses equal TLS credentials for both TLS tunnels. This way the server knows both TLS tunnels established per client.
Note: The client device needs 2 HTTP/TLS connections per „app“ and server port number. In this sense, each „app“ running on the connected device represents an independent client and has to use an own certificate.

Go to forum: wolfSSL

20 Reply by cxdinter

(2 replies, posted in wolfSSL)

Hi Kaleb,
    I got it.
    thank you!

Go to forum: wolfSSL

21 Topic by cxdinter

(8 replies, posted in wolfSSL)

Hi,
   Our product have a requirement : it should be establish two different TLS tunnels between client and server on the same IP address and port !
   Before, I haven't any experience about this situation. I searched related information on Google, and found that SNI(Server Name Indication) maybe can reach this requirement. Below is my assumption, please help me to review it, is it possible?

   In wolfSSL library, there are have one macro named "HAVE_SNI". If I enable this macro, and set different sever name for these two TLS connection, then client/server will receive correct data for different tunnels(maybe wolfSSL API already implemented).

   But for my understanding, for the same IP address/port, we only can bind one socket with it. So, how to create two TLS connections in one thread environment? My means is : can we use same TLS context(WOLFSSL_CTX* type), and create two SSL(WOLFSSL* type) connection base on this context?

   If my assumption is not possible, please give me some suggestion.
    Thank you very much!

Go to forum: wolfSSL

22 Topic by cxdinter

(2 replies, posted in wolfSSL)

Hi,
   is there any wolfSSL API used for check current session is invalid or not?
   During TLS communication, sometime we need to resume session, but how can we know current session is invalid or not?

   I found there have one function name is wolfSSL_get_session_stats(), but its parameter is not related current SSL(WOLFSSL* type), and macro WOLFSSL_SESSION_STATS is not enabled for most scenarios.

   is it possible to give me any suggestion and sample code??

    Thank you.

Go to forum: wolfSSL

23 Reply by cxdinter

(4 replies, posted in wolfSSL)

HI dgarske,
    OK. If I have finished some new function in openssl compatibility layer, and test it ok. I will paste source code here.

Go to forum: wolfSSL

24 Reply by cxdinter

(4 replies, posted in wolfSSL)

Hi dgarske,
    Thank you.
    We got benefits from your new patch. Even some of them are not really implemented.

    Actually, We have two choices to replace openssl by wolfSSL  for Poco library.
    First way is using wolfSSL's compatibility layer. The second way is : remove netssl component(based on openssl) in Poco library, and use wolfSSL APIs directly.

   I am not sure which way is more better.
   The first way is a conservative strategy, it should be ok after wolfSSL compatibility layer fully implemented.
   The second way have more challenges, but it is also let us exciting.

   By the way, in wolfSSL samples, is there any mature sample code which used for test server/client connect through TLSv1.2 ?

Go to forum: wolfSSL

25 Reply by cxdinter

(6 replies, posted in wolfCrypt)

Hi dgarske,
    Nothing else.
    This topic can be closed. Thanks a lot.

Go to forum: wolfCrypt