1 Reply by todaysSawer

(3 replies, posted in wolfSSL)

Thanks John,

Not sure how to mark this "solved" but I will try...

- Bill

Go to forum: wolfSSL

2 Reply by todaysSawer

(3 replies, posted in wolfSSL)

To be precise, TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 is described in RFC 5487, however the key exchanges are performed as in RFC 4279:

"The following six cipher suites use the new authenticated encryption
   modes defined in TLS 1.2 with AES in Galois Counter Mode [GCM].  The
   cipher suites with the DHE_PSK key exchange algorithm
   (TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 and
   TLS_DHE_PSK_WITH_AES_256_GCM_SHA348) provide Perfect Forward Secrecy
   (PFS).

      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256        = {0x00,0xA8};
      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384        = {0x00,0xA9};
      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256    = {0x00,0xAA};
      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384    = {0x00,0xAB};
      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256    = {0x00,0xAC};
      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384    = {0x00,0xAD};

   These cipher suites use authenticated encryption with additional data
   (AEAD) algorithms, AEAD_AES_128_GCM and AEAD_AES_256_GCM, as
   described in RFC 5116.  GCM is used as described in [RFC5288].

   The PSK, DHE_PSK, and RSA_PSK key exchanges are performed as defined
   in [RFC4279]."

Go to forum: wolfSSL

3 Topic by todaysSawer

(3 replies, posted in wolfSSL)

Hi,
I am using wolfSSL embedded SSL version 2.9.4. I modified the suites tables to add TLS_DHE_PSK_WITH_AES_128_GCM_SHA256.

According to RFC 4279, I do not use certificates in the handshaking between my server and my client. However I found in many places the "NO_CERTS" preprocessor directive that forbids me to use the serverDH_P field, for instance, of the WOLFSSL_CTX struct.

If I try to use certificates with Diffie Hellman key exchange and with PSK, however, I ran into a problem with the SendCertificate when allocating an output buffer. Long story. But in the internal.c initialization section there are lots of areas that are affected by the NO_CERTS directive which also include data structures used by Diffie Hellman key exchange.

Also in the SendServerKeyExchange function in internal.c where ssl->specs.kea == diffie_hellman_key, the code assumes we have a private key, which is a RSA private key but not a pre shared key.

I went through my wolfSSL code and where it had the NO_CERTS, I added a || (!defined(NO_DH) && !defined(NO_PSK)) and I got a NO_PRIVATE_KEY error in the sendServerKeyExchange

My keys.c has this block I added:

#ifdef BUILD_TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
    case TLS_DHE_PSK_WITH_AES_128_GCM_SHA256:
        ssl->specs.bulk_cipher_algorithm = cyassl_aes_gcm;
        ssl->specs.cipher_type = aead;
        ssl->specs.mac_algorithm = sha256_mac;
        ssl->specs.kea = diffie_hellman_kea;
        ssl->specs.sig_algo = anonymous_sa_algo;
        ssl->specs.hash_size = SHA256_DIGEST_SIZE;
        ssl->specs.pad_size = PAD_SHA;
        ssl->specs.static_ecdh = 0;
        ssl->specs.key_size = AES_128_KEY_SIZE;
        ssl->specs.block_size = AES_BLOCK_SIZE;
        ssl->specs.iv_size = AEAD_IMP_IV_SZ;
        ssl->specs.aead_mac_size = AES_GCM_AUTH_SZ;

        break;
#endif

Am I totally off base here?

thanks

Bill

Go to forum: wolfSSL

4 Topic by todaysSawer

(1 replies, posted in wolfSSL)

I'm in a deep discussion with a colleague about the basics of connecting a client and server.

I read the wolfSSL manual and ran the Linux as well as Windows versions (on Linux and on a Windows 8.1 via Visual Studio).

The client and server tests use sockets. Each creates a ssl object and calls the ssl_set_fd to associate the ssl object with a socket descriptor after the client does the TCP_Connect and the server finishes the TCP_Accept.

I know that the ssl object has fields which include the connection state of the client and server. These fields are used in the handshake by both. For example, the client's wolfSSL_Connect executes a while loop to wait for the needed state, which nominally would be server_hello_done or something like that.

The underlying socket software, I claim, is allowing both the client and server to access the ssl object between them. If not for the ssl_set_fd, then each executable has its own ssl and the handshake would never complete.

Am I right? Or is there a different way without modifying my wolfSSL to use it without sockets? I'm interested in the context of connection establishment mainly and I am aware of being able to customize input/ioutput with the callbacks (to skip tcp/ip). But the callbacks still do not preclude the use of sockets for a connection establishment.

thanks

Bill

Go to forum: wolfSSL