Let me chime in here and lend support to what Paul is saying. Implementing crypto algorithms, while not always as easy as it seems, is actually the easy part. In addition to the requirement of implementing the algorithm correctly, you also have to worry about:
* side effects on the environment (especially in image based systems like Squeak where objects are called into existence for a short period of time, then fall out of scope, potentially without being zeroized) * how crypto objects are used... are the encryption classes implemented in such a way that mere mortals can use them? are there, like the BSAFE API, aspects that are chronically mis-used? If so, does it affect the security of the system? * what features surround the crypto bits? msh-crypto divides things into core crypto and crypto apps. Core crypto includes algorithms, crypto apps include things like signature generation, PKCS#5 & 12 PBE, PKCS#7 message production, etc. * how does the crypto support the overall security objectives of the environment or the application? Over on the Spoon project we're starting with more general security objectives (protection of sensitive data, resistance to loss of control of the flow of execution, ability to verify the integrity of the origin of code fragments (and messages in general, etc.) and ensuring that crypto is provided in support of those objectives.
Also... I was recently asked about what books I would recommend on crypto/security. I blogged my response at http:// www.cryptonomicon.net/msh/2006/01/software-security-bookshelf.html. Two references that are especially apropos to this discussion include Matt Bishop's "Computer Security : Art and Science" and Menezes, et al., "Handbook of Applied Crypto" ( which is available for download at the HAC site at http://www.cacr.math.uwaterloo.ca/hac/). Another book I'm trying to get more people to read is "Security and Usability : Designing Systems that people Actually Use" from O'Reilly. Finally... there are a number of articles that come available at the IACR ePrints archive at http://eprint.iacr.org/ . It might be unrealistic to think that everything that gets published there will be "accessible," but I like to read these articles to a) learn something new every now and again and b) to make sure I'm keeping up with the notation and language used to describe the maths side of data security.
Finally... just a note about testing and documentation... A lot of open source projects are really just hobbies with people writing code for their own personal uses; once the code is written then it is shared with the attitude of... "heck, I'm not going to sell it, and it might be useful to someone else, so why not publish it with a FOSS style license." There is absolutely, positively nothing wrong with this. However... there are other reasons why people are interested in open source. One of the reasons I'm interested in Squeak is that for the most part, I really like Smaltalk. With a little fixing up, Squeak could easily be used for a myriad of commercial applications. When I was at Handspring, we used Squeak to prototype our systems, especially the security components. Why Squeak? a) it was free, b) it was Smalltalk, and c) it was a little easier to deal with than writing full prototypes in C++ or C.
Yeah... I know... I'm taking a while to get to my point...
But my point is... I'm interested in driving commercial adoption of Squeak so I can get paid to program in Squeak rather than C or C++. Before you get anything resembling commercial adoption of a language, there are a couple things that need to be addressed:
* Manageability * Security * Internationalization * Data Persistence
I think Squeak has _something_ to say in all these areas, but for the security section to be "approved" by CIOs and application developers, you have to have quality documentation and appropriate tests to insure your implementation is implemented correctly, does not leak sensitive information and does not generally weaken the overall security of the system (ala WinXP SP2).
As an example, msh-crypto does not implement things that are not documented and are not tested.
Just my $0.02...
-Matt H.
P.S. - Paul... good to hear you're on the list...
On 10 Jan 2006, at 06:11, Paul Crowley wrote:
Cees De Groot wrote:
Personally, but I'm known to hold extreme opinions on some matters, I think that no-one should be allowed to implement any crypto code unless after reading Schneier's Applied Cryptography. Preferably not more than a day in advance :-)
I'm going to sound like a curmudgeon when I say this, but I have a real dread of cryptography implemented by those who have read Applied Cryptography, which provides just enough information to be dangerous, and has in practice resulted in many cryptosystems which are buzzword compliant ("256-bit AES!") and dangerously broken.
What is being attempted here is not merely implementation, but protocol design, and cryptographic protocol design is an extremely advanced and difficult science which should not be attempted by those who do not understand in detail the proofs that underlie constructions such as OCB mode or PSS. Even those who do are prone to making dangerous mistakes; review by other experienced people is essential. At a minimum, the cryptography in use should be documented in detail; it should not be necessary to refer to the source code to discover things like that ECB mode was used to encrypt the messages.
If at all possible, find an existing, well-respected standard and use that.
See http://diswww.mit.edu/bloom-picayune/crypto/14238 for some more curmudgeonly sentiment from Peter Gutmann on a related subject. -- [][][] Paul Crowley [][] LShift Ltd [] [] www.lshift.net _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography