Crypto, a Villain, and You (was: Re: [squeak-dev] Re: [Cryptography Team] Re: DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Crypto, a Villain, and You (was: Re: [squeak-dev] Re: [Cryptography Team] Re: DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random)

Casey Ransberger-2
<villain type="mustachioed">

I think crypto is a strong candidate for "community supported package."

I want to say that I think this is incredibly admirable work; the educational value alone cannot be overstated. I've been meaning to look at this stuff, because I think it's endlessly cool, and I pray my next statement will harm none...

I also think that crypto vetted by such a small community is extremely *dangerous*, if just because new users might confuse it with the much more well-vetted platform crypto that most programming systems make use of (I'm ill-educated here, so forgive me if I'm totally ignorant of something critical; I hope that WithPrimitive means "hooks into platform crypto," not "goes faster.")

</villain>

On Thu, Aug 26, 2010 at 9:48 PM, Andreas Raab <[hidden email]> wrote:
On 8/26/2010 4:02 PM, Chris Muller wrote:
Folding Cryptography into Squeak would probably go against the
political momentum toward smaller, more modular images.

I'm not entirely sure about this. The problems with the Crypto package as I see it are:

1) It carries a lot of dead weight. It might be educational to carry an implementation of MD2 but it's also completely *useless*. So my take here would be to have two packages "Crypto-Core" and "Crypto-Extras" and move all of the non-essential stuff to Crypto-Extras.

2) It has too many variations (all those *WithPrimitive and *NonPrimitive) variants. There's no need to have both; write the primitive variants so that they use non-primitive fallback code or simply require the primitives.

3) ASN1, X509, PKCS. This is not cryptography, this is certificate handling. It should be in a Certificates package, not Cryptography.

4) A category per class. Puh-lease...

If you do all of the above you'll end up with one or two "Crypto-Core" categories containing all of the "essentials" like MD5, Triple DES, DSA, RSA, SHA1, SHA256. That's probably about what you'd want in the base image and I'd be surprised if it's more than 20 classes. I think you could make a *very* reasoned case that this Crypto-Core should be included in the trunk image by default in particular considering that it would remain loadable and simplify the System (and other) packages.

Then you have Crypt-Extras with the less common stuff, from MD2 to DiffieHelman. On top of which is the Certificate package with ASN1, X509, and PKCS. On top of which is the SSL stuff.

I think this would be quite a nice structure and I'd be supporting getting a small Crypto-Core package into trunk. Anyone up for it?

Cheers,
 - Andreas




--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: Crypto, a Villain, and You (was: Re: Re: [Cryptography Team] Re: DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random)

Andreas.Raab
On 8/27/2010 12:51 AM, Casey Ransberger wrote:
> I also think that crypto vetted by such a small community is extremely
> *dangerous*, if just because new users might confuse it with the much
> more well-vetted platform crypto that most programming systems make use
> of (I'm ill-educated here, so forgive me if I'm totally ignorant of
> something critical; I hope that WithPrimitive means "hooks into platform
> crypto," not "goes faster.")

Yes you are a bit ill-educated :-) First, the actual crypto algorithms
(hashing, signing, encrypting, key exchange) are very small, very well
documented and very easy to test. There are reference implementations
and tests for all of them and it's virtually impossible to implement one
of these algorithms wrongly and yet pass these tests.

"With primitive" in this context really means "goes faster" not "hooks
into the platform" for precisely the reasons above. You will find that
if you look at systems like Python and others that they do include their
own implementation of these algorithms for precisely the same reasons.

Lastly, I'm not aware of *any* attack that has ever been used against a
"wrong implementation" of some part of the core crypto code. Some
algorithms have been broken entirely (such as MD2 or MD4) but generally
when we hear about attacks, they're not in the simple crypto parts but
rather include attacks against certificates, encodings etc. In
particular certificate encoding and verification appears to be a prime
vector for attacks. But MD5? SHA1? Not likely.

Cheers,
   - Andreas