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 :-)

Seconded! Er, I shall have to get my copy shipped over from New Zealand if I want to contribute here then! ;-)

On 1/10/06, Paul Crowley paul@lshift.net wrote:

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.

Err... I hope you dread this kind of crypto less than that written by (lay)people that haven't read the book at all :).

In any case, your point is exactly the point that Schneier makes over and over again - if people ignore that point, they're beyond help.

So if I implement crypto code, I use a) recommended protocols - lots of sound recommendations in the book, and b) test my implementation against an existing implementation (like openssl) with a handful of test messages. So, apart from a description of the protocol followed, I always like to see self-test code with a reference to where the test data was obtained.

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

On Jan 10, 2006, at 10:30 AM, Ron Teitelbaum wrote:

Does anyone have a suggestion for how to certify our code?

In general... when talking about Security, you want to have the design reviewed prior to having the code reviewed... but I guess we can be agile about it. Maybe the thing to do would be to document what we have in terms of architecture, find someone to do an independent review of the architecture, incorporate architecture changes recommended by the reviewer, then make code changes, then have the code reviewed.

The word "certify" has a lot of different meanings to different people. If you're looking for FIPS certification, that's a long process... and it costs money. The OpenSSL FIPS certification process has been going on for at least a year or two with the bill being footed by OSSI, HP, DoD and a couple other people whose names escape me at the moment.

The motivation there was that HP and DoD believed the certification was an investment... pay a little up front so they can benefit from the cost savings of using an open implementation of various crypto algorithms. The last time I was involved in a CMVP effort, the total bill to the independent lab was something on the order of about $12k US. With the recent devaluation of the US peso, I'm guessing it would probably run at least $18k US these days.

I think it would be helpful if what we have done to prove our work (testing documentation ...), the qualifications of the person writing the code, and any reference materials were all kept in a single place. It would be helpful as a reference for others, and some proof that may be needed before someone considers adoption. What do you all think?

I definitely agree with this!

I see that FIPS140-2 states that the certification is intended for sensitive, not classified information. Is it possible for us to be certified for classified information, or is that certification out of reach?

Ron

_____

From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Ron Teitelbaum Sent: Tuesday, January 10, 2006 6:35 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Squeak Cryptography Team Code CommercialAcceptance

Matt,

Thanks for the information, I will review the process. I would think we could come up with the money you suggested to get certified.

So to update our goals:

5) Get external US Government certification of Security for external package and image components.

Should be changed to:

5) Complete Cryptographic Module Validation Program (CMVP) through the OpenSSL Federal Information Processing Standard (FIPS) Certification Process.

5.1) Identify Experts in Group (recruit new members?)

5.2) Find repository and define structure for documentation.

5.3) Document current frameworks

5.4) Develop new designs, following design goals (tbd through open discussions) and document new framework.

5.5) Expert Design Review and Implementation recursively until code complete

5.6) Identify Team Leaders to walk our project through OpenSSL FIPS Cert Process

5.7) Raise Money for Cert Process

5.8) Complete Certification, Publicize results

5.9) Offer Reward for anyone that breaks code

5.10) Set up review committee that reviews implementations (for a fee) and helps others get certified using our code.

Does anyone have any comments on the change?

Ron Teitelbaum

Squeak Cryptography Team Leader

Ron@USMedRec.com

_____

From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Matthew S. Hamrick Sent: Tuesday, January 10, 2006 4:22 PM To: Ron@USMedRec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Squeak Cryptography Team Code CommercialAcceptance

On Jan 10, 2006, at 10:30 AM, Ron Teitelbaum wrote:

Does anyone have a suggestion for how to certify our code?

In general... when talking about Security, you want to have the design reviewed prior to having the code reviewed... but I guess we can be agile about it. Maybe the thing to do would be to document what we have in terms of architecture, find someone to do an independent review of the architecture, incorporate architecture changes recommended by the reviewer, then make code changes, then have the code reviewed.

The word "certify" has a lot of different meanings to different people. If you're looking for FIPS certification, that's a long process... and it costs money. The OpenSSL FIPS certification process has been going on for at least a year or two with the bill being footed by OSSI, HP, DoD and a couple other people whose names escape me at the moment.

The motivation there was that HP and DoD believed the certification was an investment... pay a little up front so they can benefit from the cost savings of using an open implementation of various crypto algorithms. The last time I was involved in a CMVP effort, the total bill to the independent lab was something on the order of about $12k US. With the recent devaluation of the US peso, I'm guessing it would probably run at least $18k US these days.

I think it would

be helpful if what we have done to prove our work (testing documentation

...), the qualifications of the person writing the code, and any reference

materials were all kept in a single place. It would be helpful as a

reference for others, and some proof that may be needed before someone

considers adoption. What do you all think?

I definitely agree with this!

Hey Tony...

Thanks for joining the fray. I'm going to express an unpopular opinion here... Sometimes the Wikipedia is _not_ the reference of choice. It's a great place to start (as with any Encyclopedia) but it's focus is, as far as I can tell, to be broad rather than deep.

So I'm not trying to criticize here... not you... not the Wikipedia...

I just wanted to offer a few additional resources for modes of operation that I consider a little more authoritative.

http://csrc.nist.gov/CryptoToolkit/modes/

and

http://csrc.nist.gov/CryptoToolkit/modes/workshop1/index.html

The first is an overview of the modes of operation section of NIST's "Crypto Toolbox". The second links to the proceedings of a conference on the subject.

On 10 Jan 2006, at 05:38, Tony Garnock-Jones wrote:

Hi Chris,

ECB, CTR ("Counter"), EAX and GGM are all modes of operation for block ciphers. This wikipedia page http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation provides a good overview of the different modes, and why ECB is a bad choice, and why an AEAD mode (near the bottom of the page) is better than a non-authenticating mode.

(I was particularly struck by the spectacular failure of ECB mode to encrypt the sample image!)

With specific reference to a Mako signed-sealed envelope, probably the best thing to do is to perform the public-key signing operation on the original data, and then encrypt-and-MAC the signed data as a separate step. The thing to do is to change the way envelopes are sealed (the signing process can be left alone) to be an encrypt-and-MAC operation rather than a simple encrypt-only operation with no integrity protection. For instance, Rijndael in EAX or GGM mode would do nicely for the enciphering step.

Another thing to watch out for is the key-exchange protocol, which can be really sensitive.

Cheers, Tony

Chris Muller wrote:

...

Hi Tony, it may very well be the other way around. I am honestly no encryption expert, just a skilled implementor. I will try to find the web reference that recommended that.

As for ECB, I'm sorry I have no idea what that means. This is exactly the kind of critique I need your guys' help with. I am hoping that the usage and management are mostly ok, but there may be some tightening needed in the cryptography layer.

This is a very worthy discussioon for the cryptography list, I hope you don't mind that I have copied that list here.

Cheers, Chris

--- Tony Garnock-Jones tonyg@lshift.net wrote:

...

Hi Chris,

In the comment to method MakoEnvelope class>>signedAndSealedFrom:to:object:, you write "Security experts recommend putting the signed inside the sealed".

Isn't it the other way around? According to http://www-cse.ucsd.edu/users/mihir/papers/oem.html the least insecure method is to encrypt, then MAC.

Also: On digging into the implementation of enciphering, it looks like the default cipher, Rijndael, is being used in ECB mode. Have I analysed that correctly? (If so, there are other modes that might be better: AEAD modes such as EAX or GGM; at a minimum, CTR, but an AEAD mode would be better, of course)

Regards, Tony

-- [][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211 [][] LShift Ltd | Tel: +44 (0)20 7729 7060 [] [] http://www.lshift.net/ | Email: tonyg@lshift.net _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography