Optimizing use of SSL?

[Ben Greear]

On 02/02/2011 03:38 PM, Ben Greear wrote:
> I've been looking at ways to optimize wpa_supplicant for when we are using
> lots and lots of vifs (say, 128).  These are configured to use WPA,
> and the NIC (ath9k) is set to software-encryption in order to work with multiple
> vifs.
>
> I ran it under callgrind (valgrind --tool=callgrind) with only
> 16 vifs, and libcrypto seems to be using most of the CPU.
>
> I'm wondering if anyone has any ideas for ways to optimize
> supplicant to work better in this case.  I was thinking it
> should only be passing relatively few pkts around, so I'm
> not too sure why it's such a CPU hog.

Hrm, seems that a lot of the cost is calculating
the digest:

   Frame: Backtrace for Thread 1
    [ 0]  EVP_DigestInit_ex (209361 x)
    [ 1]  openssl_digest_vector (209361 x)
    [ 2]  sha1_vector (104681 x)
    [ 3]  hmac_sha1_vector (104655 x)
    [ 4]  hmac_sha1 (104629 x)
    [ 5]  pbkdf2_sha1 (13 x)
    [ 6]  wpa_config_update_psk (13 x)
    [ 7]  wpa_config_read (13 x)
    [ 8]  wpa_supplicant_add_iface (13 x)
    [ 9]  main (1 x)
    [10]  (below main) (1 x)
    [11]  0x0804c220 (1 x)
    [12]  0x4d80d870

Specifically, this method has a pretty mean loop:

pbkdf2_sha1_f()

It loops for all iterations, which is passed in as 4096
by this method below:

/**
  * wpa_config_update_psk - Update WPA PSK based on passphrase and SSID
  * @ssid: Pointer to network configuration data
  *
  * This function must be called to update WPA PSK when either SSID or the
  * passphrase has changed for the network configuration.
  */
void wpa_config_update_psk(struct wpa_ssid *ssid)
{
#ifndef CONFIG_NO_PBKDF2
	pbkdf2_sha1(ssid->passphrase,
		    (char *) ssid->ssid, ssid->ssid_len, 4096,
		    ssid->psk, PMK_LEN);
	wpa_hexdump_key(MSG_MSGDUMP, "PSK (from passphrase)",
			ssid->psk, PMK_LEN);
	ssid->psk_set = 1;
#endif /* CONFIG_NO_PBKDF2 */
}


Is it required to do that 4096 times, or is it just higher
grade encryption that way?  If something lesser would be
adequate, maybe I can make it a configurable value?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com