pfSense

Several packages, as well as base, have GUI where the user can specify a cipher, digest, or other encryption-related standard. The options for these selections seem to have issues:

1. They are scattered around and often hard-coded, making them harder to review and periodically update as a whole.
2. They often present an apparently inadequate range which does not cover the current recommendations for use by major bodies.
3. There is no page which allows easy admin setting of permissible crypto options (beyond a very basic "allow , so the only way to confirm if undesirably weak crypto is permitted in some function is to check every GUI where a crypto method can be specified.
4. Defaults and options are at times presented which are currently considered to be effectively broken and should really not be suggested any more, or at least not as defaults (DH=1024 in OpenVPN, MD5 as a digest, etc)
5. In some circumstances such as longer term resistance to retrospective analysis or decryption of sessions and data (>2030 or >2040) NIST refers to FIPS 140-2 (table 2 p.88) and recommends asymmetric keys >7680 bits or >15360 bits. The European Union Agency for Network and Information Security (ENISA) concurred back in 2013 that crypto based on RSA, DLP and pairing and requiring long term resistance should use >15360 bits. But no pfSense setting where asymmetric key size is entered, allows >4096 bits even if this is recommended in some cases.

Some pfSense functions do allow a full range of options, for example openVPN gets its list of digests and ciphers directly from openVPN and therefore supports all.

POSSIBLE IMPROVEMENT?

1. Move the hard-coded lists and the most important defaults to more obvious locations where they can be maintained more accessibly.
2. Create static tables of common descriptors for the most common crypto methods, such as "considered broken", "legacy", "current use", "future use", "long term use", "may break compatibility" etc. Then, where the GUI allows a user to select a crypto method (almost always a dropdown selector) note after the crypto method, the groups it's in, so the user can see for each method, its current status. For example, SHA1 might appear as "SHA1 (considered legacy, use stronger if able)" while an 8192-bit key might appear "8192 bits (currently excessive, recommended for >2030 only; may not be compatible with all software)", or similar. This would greatly help people to choose appropriate key sizes rather than guessing at random or using outdated information. As recommendations are only updated every year, or every few years, categorising this way this would not be burdensome or need constant updates, it could be updated annually or 2-yearly with new releases of the firmware, or checked automatically every X days much like bogon tables (nicer?).

It might also be easy to provide a simple usage tracker to identify when a crypto method that has been used, changes category, and warn the user.