It's a little embarrassing that we provide some archaic crypto primitives with a lot of trouble to link against OpenSSL, mcrypt, and mhash. Nobody should be using any of these in new protocols or most new applications.
There are a few standard protocols like IMAP and HTTP that use MD5, so while it shouldn't be used in any new protocols, it may be reasonable to keep around for new applications implementing old protocols. But we could just adopt (or write afresh) a portable C or Scheme implementation -- no need to deal with linking against OpenSSL or mhash. Edwin's file encryption -- which does not withstand scrutiny of modern crypto engineering -- currently uses Blowfish. Since some people (cph?) may still have files stored this way, it may be reasonable to keep this for that purpose. But again, we could just adopt a portable C or Scheme implementation and forget about OpenSSL or mcrypt. We definitely shouldn't advertise Blowfish as `one of the faster block ciphers' -- it is much slower and more memory-intensive than, e.g., AES or Threefish, which are the only two block ciphers I would consider using today -- and any documentation about it should warn that it is a long-outdated algorithm whose 64-bit block size makes it unsafe to use unless you really know what you're doing. I'm not even sure we should be documenting this. (I realize that the text I quoted was copied from the OpenSSL man pages. Unfortunately, OpenSSL man pages turn out to be bad news!) I polled mit-scheme-users for who uses these and for what. Anyone here have thoughts on this? I'm volunteering to do the work to provide drop-in MD5 and Blowfish code replacements in microcode/, and get rid of the rest if nobody objects. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel