Out of interest, what crypto does NetworkManager do internally?

The version which was examined (0.6.4) contained internal implementations of
SHA-1 and MD-5.

We should be looking at 0.7, which has the following requirements:

1) SHA1 (for WPA passphrase hashing) and MD5 (for WEP passphrase hashing and
small hash table key generation)

2) PEM and DER certificate verification: ensuring that the data in a random file
the user specifies is in fact a PEM or DER certificate

3) Decrypting PEM or DER private keys with a given passphrase: since we do not
want wpa_supplicant reading all over the drive for security reasons (and easier
ability to lock down a network-facing root-level daemon), we do not pass
certificate/key paths to the supplicant.  Instead, the user agent that stores
the file path (nm-applet in most cases) decrypts the private key with the given
user passphrase (which is also stored in the user session keyring) and sends the
decrypted private key to NetworkManager, which forwards the key or certificate
data to the supplicant as a binary blob.


The _ideal_ situation with NSS is that NetworkManager would require that all
certificates and private keys be imported into the user or system certificate
databases, and then NM would simply pass a token down to the supplicant, which
would then query the certificate database for the appropriate data.

However, there is no NSS backend for wpa_supplicant at this time, thus somebody
would have to write one.  wpa_supplicant currently uses OpenSSL to perform the
certificate verification, encryption, and other operations required by WPA and
WPA2 Enterprise standards.  It would need access to _both_ the user's and system
certificate database unless we require all users to import their certificates
and keys into the system certificate store.  Last I knew a root-level daemon
like wpa_supplicant could not access a user-sessions certificate store.

NM itself has actually used NSS for everything since 0.7.x.  Obviously wpa_supplicant still needs NSS support.