1 Reply by yun

(2 replies, posted in wolfSSL)

Hi,

I found the answer to my questions:

1) Vulnerabilities reported by the Google Security team are described here in wolfSSL Security Advisory:
http://www.yassl.com/yaSSL/Blog/Entries … _2014.html

It would be helpful, if the change log had a link to this blog.

2) Vulnerabilities reported by Suman Jana is described here: http://cve.mitre.org/cgi-bin/cvename.cg … 4-1959.The affected function in CyaSSL is ParseCertRelative() in asn.c.

Regards,
Yun

Go to forum: wolfSSL

2 Topic by yun

(2 replies, posted in wolfSSL)

Hi,

I am using CyaSSL embedded SSL release 2.9.0. According to the Changelog http://www.yassl.com/yaSSL/Docs-cyassl-changelog.html, releases 2.9.4 and 3.0.0 have fixed security bugs reported by Ivan Fratric of the Google Security Team and Suman Jana at UT Austin and UC Davis. Could you please give me some detail about the nature of fixed issues? Otherwise I have to do a code comparison to find out these details.

Thanks,
Yun

Go to forum: wolfSSL

3 Topic by yun

(1 replies, posted in wolfSSL)

Hi All,

We have been using the SSL functionality of wolfSSL embedded SSL and everything until works fine. We are using wolfssl-2.6.0.

In ssl.c in the method ProcessBuffer() for private key handling, starting from  line number 1425:  

        if (type == PRIVATEKEY_TYPE && format != SSL_FILETYPE_RAW) {
#ifndef NO_RSA
            if (!eccKey) { 
                /* make sure RSA key can be used */
                RsaKey key;
                word32 idx = 0;
        
                InitRsaKey(&key, 0);
                if (RsaPrivateKeyDecode(der.buffer,&idx,&key,der.length) != 0) {
                 ...
              }

This block tries to construct a RsaKey from a encoded key in DER format to make sure that the encoded key can be used later. As I understand, RsaPrivateKeyDecode() is used to decode a key in DER format into RsaKey. Then line 1425 shall be 

        if (type == PRIVATEKEY_TYPE && format == SSL_FILETYPE_RAW)

instead of 

        if (type == PRIVATEKEY_TYPE && format != SSL_FILETYPE_RAW)

Is it correct what I understand?

Thanks, Yun

Go to forum: wolfSSL

4 Reply by yun

(2 replies, posted in wolfSSL)

Hi Hans-Jürgen,

I added the following function wolfSSL_check_domain_name(ssl, host) before calling wolfSSL_connect (ssl). This ensures hostname verification will be done during the handshake (in the DoCertificate() method).

Thanks!
Yun

Go to forum: wolfSSL

5 Topic by yun

(2 replies, posted in wolfSSL)

Hi All,

We have been using and testing embedded SSL functionality of wolfSSL. Until now, everything works fine. But I am wondering whether and how hostname verification is supported when the client does server certificate verification.

For hostname verification, the client shall try to match the fully qualified DNS name (IP address and port) of the requested server to one of the identifiers in the server certificate. There is the method wolfSSL_set_fd(WOLFSSL* ssl, int fd) to pass in connection information such as IP address and port. But I did not find the place in the source code where this information is used for validation.

Could you please advice?

Thanks, Yun

Go to forum: wolfSSL

6 Topic by yun

(2 replies, posted in wolfSSL)

Hi All,

I am testing AES CBC mode with IV = {0x00, 0x00, ...... 0x00} and IV = NULL.

1) Using the same plaintext message, I got different ciphertexts with IV = NULL and IV has all 0x00 values.
2) On a machine of my colleague, the same plaintext message and IV = NULL resulted into another different ciphertext than on my machine.

I think the behavior is not correct, right?

I dived into aes.c source. IV is copied to aes.reg. If IV = NULL, aes.reg is not initialized. But AesCbcEncrypt() performs xorbuf((byte*) aes->reg, in, AES_BLOCK_SIZE) independently, whether aes->reg has been initialized before.

Thanks, Yun

Go to forum: wolfSSL

7 Reply by yun

(5 replies, posted in wolfSSL)

Hi Chris,

Sorry for the late response! I have using a 32 bit processor environment, and the lcc compiler. As far as I know, lcc does not have 64bit support.

Without USE_FAST_MATH, I have the following configuration for the 32bit environment, and everything worked fine.

#define MP_16BIT
#define CHAR_BIT      8

Now, I added

#define SIZEOF_LONG 4
#define SIZEOF_LONG_LONG 4

I still got the warning: 

ctaocrypt/src/tfm.c:105: warning: shifting an `unsigned long long' by 32 bits is undefined

.

In tfm.h, DIGIT_BIT is defined as 

#define DIGIT_BIT  (int)((CHAR_BIT) * sizeof(fp_digit))

which is 32. So I cannot get rid of the above warning.

What shall I do to get USE_FAST_MATH working for a 32 bit environment?

Thanks, Yun

Go to forum: wolfSSL

8 Reply by yun

(5 replies, posted in wolfSSL)

Hi Chris,

I am trying with the USE_FAST_MATH and TFM_TIMING_RESISTANT configuration. We have a 32 bit processor, could you please further advice how to configure for 32 bit processor with USE_FAST_MATH. I have tried with the following: 

#undef FP_64BIT
#undef CRYPT

and modified 

typedef unsigned int  fp_digit

to 

typedef unsigned short fp_digit

.
Without this modification, I got the following compilation error: 

ctaocrypt/src/tfm.c:105: warning: shifting an `unsigned long long' by 32 bits is undefined

However, using USE_FAST_MATH it was not faster for RSA, but even slower. So I assume that I am using the wrong configuration.

Additionally, I realized sizeof(mp_int) = 16 in case of without the fast math lib, and sizeof(mp_int) = 552, is it correct?

Thanks, Yun

Go to forum: wolfSSL

9 Reply by yun

(2 replies, posted in wolfSSL)

Thanks a lot for your quick help! With idx = 26, it works.

I have tried with a number of Java encoded private keys, it seems the extra information generated by Java always consumes the first 26 bytes.

Thanks!

Yun

Go to forum: wolfSSL

10 Topic by yun

(2 replies, posted in wolfSSL)

Hi All,

I have got a RSA private key in PKCS#8 DER format as output from Java (privateKey.getEncoded()), and would like to convert the DER binary into a RsaKey with the method:

RsaPrivateKeyDecode(keyDer, &idx, privateKey, sizeKeyDer);

It failed in GetInt(), since (b != ASN_INTEGER). Instead of (b = 2), in my case (b = 48, or b = 0x30). I have attached the key.

Decoding a private key in DER format generated with openSSL was successful. Could you please tell me, which format wolfSSL embedded SSL supports for the DER - RsaKey conversion?

Thanks,

Yun

Go to forum: wolfSSL

11 Topic by yun

(5 replies, posted in wolfSSL)

Hi All,

I am testing wolfSSL for embedded devices with SSL. Could you please advice the best configuration settings for runtime performance (i.e. speed)? We are running wolfSSL as pure software without any specific hardware support for crypto operations.

Especially for RSA there are a lot of configuration options to use different algorithms. In mpi_class.h I saw various configurations.

Thanks,
Yun

Go to forum: wolfSSL

12 Reply by yun

(4 replies, posted in wolfSSL)

Hi Chris,

You are right! wolfSSL's implementation is conform with PKCS#1 v1.5.

To create a signature conform with PKCS#1 v1.5, I need to do the following steps:

1. get SHA1 or SHA256 digest for the message, e.g. "digest" of size "digestSize"

2. encSigSz = EncodeSignature(encodedSig, digest, digestSize, typeH);
    For SHA1, typeH = SHAh (defined in asn.h). For SHA256, typeH = SHA256h

3. RsaSSL_sign (encodedSig, encSigSz, signedMsg, keySizeInBytes, key, rng)

The second step was not clear to me before (the manual did not mention this step).

Thanks,

Yun

Go to forum: wolfSSL

13 Reply by yun

(4 replies, posted in wolfSSL)

Hi Chris,

Thanks for your quick reply! I looked at the code in rsa.c. As far as I understand, the padding does not support the PKCS#1 padding for RSA encryption and signing.

According to PKCS#1:
For signing with RSA: The encoded message has the structure of 0x00||0x01||0XFF... 0XFF||T, whereas T encodes the ID of the hash function and Hash(M) into an ANS.1 value.

For encryption with RSA: The encoded message has the structure of 0x00||0x02||PS||0x||M.
PS can be 0XFFs or random bytes.

RsaPad in rsa.c implements the following:
Hash(M)||0X00||PS||0X00. Depending on the RSA_BLOCK_TYPE_1 (for siging) or RSA_BLOCK_TYPE_2 (for encryption), PS is either 0xFFs or random bytes.

Do I understand correctly?

Best regards,
Yun

Go to forum: wolfSSL

14 Topic by yun

(4 replies, posted in wolfSSL)

Hi All,

I am wondering whether the RSA implementation in wolfSSL supports any of the  padding schemes defined in FIPS 186-3 (ANS X9.31, PKCS #1 V1.5 or PSS).

It seems to me that the methods RsaPad() and RsaUnpad() in ctaocrypt/src do not support any of the above padding schemes.

Additionally, for signature generation, the caller must pass the already hashed message to RsaSSL_sign(). Is it correct?

Are the padding support and the hashing step implemented in another package than ctaocrypt?

Thanks,
Yun

Go to forum: wolfSSL