Thanks for taking care of this David.  Comments inlined:

> 2) cmm.11 which drops extensions to ThirtyTwoBitRegister which were
> absorbed in Squeak3.11 and are also present in 4.1.  Do we want to
> continue to include them in Cryptography package?  My suggestion is to
> move them from Cryptography to CryptoThirtyTwoBitRegisterExtensions
> which will only be loaded in pre-Squeak3.11 images.  I don't know
> anything about Metacello yet but maybe we can make it smart enough to
> load these in older images.

Well, legacy apps still using 3.9 probably don't want to upgrade to
the latest Cryptography before upgrading to Pharo or Squeak 4.1+..

I've read about Metacello, but not yet taken the time to get deeply
into it.  My sense is that we don't need it to solve this issue.
Simply a more generic package for the purpose of backward
compatibility, i.e., a "Crypto3.9Compatibility" package, could house
these extnesions?

Still, I'd bet if you just merged my version, the removal of these
extensions from Crypto, and do nothing else, there will be no
complaints.

> 3) cmm.8 contains #destroy in ElGamalKeyGenerator and String which are
> not in trunk.  The only user of the former is DiffieHellman which
> provides no path to send destroy to the generator unless it is sent by a
> third party (df generator destroy).  Methods are untested.

Please include these important changes.  ElGamalKeyGenerator is used
directly by *clients*, who call #destroy.  After generating a ElGamal
key pair and safely encrypting and saving it, it is important to then
destroy the generator so that its sensitive numbers aren't accidently
left hanging around in the image..!

These changes are essential, they should be merged.

DiffieHellman uses ElGamalKeyGenerator for a different purpose
(authentication)..

> 4) cmm.9 which adds a species check in ASN1Object>>=.  This change is
> not in the trunk but there are no tests that fail as a result of its
> absence.  Chris: do you remember your motivation for adding this?

Yes, of course, very bad breakage.  Any class implementing #= must
allow for the possibility that the comparand will not be of the same
type.  Virtually every #= implementation in the system does this.

A simple test:

  self deny: (ASN1ObjectId fromString: '1.3.6.1.5.5.7.8.5') = Object new

fails.

> For now I'll fix "1" and await feedback on others.

Thanks again,
  Chris