There's no such thing as WEP ASCII.

There are about a dozen mutually incompatible vendor-specific implementations.  Some do straight ASCII conversion, some use hashes, some are proprietary and undocumented, and even those that do straight conversions will pad with different values.

For us to try all of the combinations for the versions we currently have enough information to implement would take about 7 minutes. Do you think it's reasonable to ask people to wait that long to connect?

Unfortunately, that's only *one* of the several mapping of ASCI->HEX that various vendors use.  And even that's not enough -  where the ASCII passphrase is too short, some vendors pad with FF and some with 00, and some with other values.  If the ASCII passphrase is too long, some vendors truncate, others do different things.

Someone using your method would *completely* fail on an Apple Airport, since their ASCII->HEX conversion uses a completely different (and secret) hash algorithm.

We considered presenting a question asking about the particular vendor of the wireless access point the user is using, however, that's not enough - some vendors use different algorithms on different models, and most users have no clue who makes their access point, let alone exactly which model it is.

We also have no way to check in advance for key length in WEP - so for each algorithm, we'd have to try all of the different possible key lengths.

Trust me - we've thought about this a *lot*.

Incidentally, WPA has a more subtle problem - it *does* support straight ASCII->HEX conversion, but the specification completely omits information about the encoding of extended characters.  Most vendors use ISO-8859-1, but that's no guarantee.  Some vendors simply don't allow extended characters, effectively reducing the actual number of bits used for security by 1/8th.