[Cryptography Team] Re: KryptOn MakoEnvelope signedAndSealedFrom:to:object:

[Matthew S. Hamrick]

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 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ 
> cryptography