Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Advanced String Encryption Re:

From: joel:neely:fedex at: 5-Sep-2000 5:23

If by "create a ... function" you mean that you'd like REBOL Technologies to add a well-known, well-tested, high-security algorithm (e.g., blowfish, twofish, or whatever wins the AES competition sponsored by NIST) to REBOL as a primitive (for performance reasons) then I'm happy to second the request. This would be a valuable feature, and could be a critical part of the support for no-human-readable-source distribution of REBOL programs (also a valuable feature, IMHO). If by "create a ... function" you mean that you'd like for a group of volunteers to try to invent an en/de-cryption scheme and implement it in REBOL, I'll be strongly of the opposite persuasion: 1) REBOL should support relevant industry standards wherever feasible. As NIST is the appropriate agency, I suggest that their guidelines be followed. Please see http://csrc.nist.gov/encryption/aes/ for more information on the Advanced Encryption Standard Development Effort. 2) Cryptography is SEVERELY non-trivial. The only way that I would begin to trust a cryptographic algorithm (including some designs which I've created for fun) is for it to be a published design which has been kicked around for YEARS in the crypto community. Open source (including intensive expert peer review) is the only way to achieve reliable cryptographic security. Please see http://www.counterpane.com/ and http://www.wired.com/news/technology/0,1282,38240-2,00.html for more information on this. 3) Strong crypto is usually computationally intensive. While I strongly advocate reserving performance optimization for those critical parts of a system where there's really a need for it (development/testing/maintenance time are usually much more expensive than run time for the majority portion of the majority of computer programs), an en/de-cryption function is one such hot spot, IMHO. 4) If the whole point of crypto is security, then en/de-cryption functions should be embedded into the language in a way that minimizes the possibilities for a running piece of code to change or replace them (or otherwise interfere with their function). We all know that user-defined and official mezzanine functions are vulnerable to modification (intentional or otherwise). Please let me be clear that I am NOT trying to discourage or look askance at any efforts toward experimentation or research into cryptography, nor am I suggesting that REBOL is a bad choice for such efforts. But I AM saying that amateur/experimental/research efforts by the REBOL community should not be the basis for "official" (in any sense of the word) support for crypto in the REBOL language. -jn-