On Sun, 9 Jun 2019 at 22:09, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > Hi Ard, > > In general, I have no objections to this. > > However, with this > > > - select CRYPTO_ARC4 > > + select CRYPTO_LIB_ARC4 > > and this > > > case WLAN_CIPHER_SUITE_WEP40: > > case WLAN_CIPHER_SUITE_TKIP: > > case WLAN_CIPHER_SUITE_WEP104: > > - if (IS_ERR(local->wep_tx_tfm)) > > - return -EINVAL; > > - break; > > there's one quirk that I worry about. Does this mean WEP is now *always* > available/enabled? > > I had to dig in history a bit, but vaguely remembered this commit: > > commit 3473187d2459a078e00e5fac8aafc30af69c57fa > Author: John W. Linville <linville@xxxxxxxxxxxxx> > Date: Wed Jul 7 15:07:49 2010 -0400 > > mac80211: remove wep dependency > > > Since you create the new CRYPTO_LIB_ARC4 in patch 1, I wonder if > something is broken? I can't really seem to figure out how WEP is > disallowed in FIPS mode to start with though. > > > (This also is the reason for all the code that removes WEP/TKIP from the > list of permitted cipher suites when ARC4 isn't available...) > Good point. And in the future, there may be other reasons besides FIPS compliance to turn off WEP support, so it makes sense to retain this logic. I am still curious whether FIPS compliance actually requires us to do this, or whether that code is simply there to work around the lack of RC4 in the crypto API when FIPS support happens to be enabled.
