[Python-ideas] adding digital signature and encryption "hashes" to hashlib?
debatem1 at gmail.com
Tue Sep 22 03:37:34 CEST 2009
On Sep 21, 5:37 pm, Bill Janssen <jans... at parc.com> wrote:
> CTO <debat... at gmail.com> wrote:
> > On Sep 21, 11:43 am, Bill Janssen <jans... at parc.com> wrote:
> > > CTO <debat... at gmail.com> wrote:
> > > > > I know it seems that way at first glance, but in fact they are strongly
> > > > > related. There's a reason all three (and nothing else) are exported
> > > > > through OpenSSL's EVP API.
> > > > > Bill
> > > > Don't get me wrong, I like the basic idea you're advancing, and in
> > > > use hashes and crypto are frequently seen together,
> > > Yes, that's the relationship I was thinking of. But from a broader
> > > philosophical view, a ciphertext can be thought of as a hash of a
> > > plaintext, too. A reversible hash.
> > You really shouldn't conflate these things. The point of a hash is
> > to ensure message integrity, while the point of encryption is to
> > preserve secrecy. As an example, ElGamal is a common cryptosystem
> > that nevertheless preserves the multiplicative homomorphism..., ie,
> I know lots of non-crypto users -- the people the "batteries included"
> aspect of Python are for -- that don't understand the fine points of
> this, and don't want to. They just want to encrypt some text with a
> "good" cipher scheme, and they depend on the library implementor to know
> how to do that. They want a function "encrypt(plaintext, key)", and
> don't really want to know more than that.
Crypto is complex for a reason. I didn't point those examples out
because they were exceptions to the rule, I pointed them out because
in crypto the rule is that your ignorance will burn you in the end.
Trying to make it easier to do security badly is not a goal I'd set
for the standard library.
> And, by the by, hashes are often used for purposes other than message
> integrity, outside the sphere of crypto.
Cryptographic hashes were designed to be used in cryptography. Any
other use should be well-researched before being deployed. Bad
commmon practices aren't less bad for being more common.
> > > > IMO, adding public key crypto routines to hashlib seems almost
> > > > guaranteed to increase that confusion.
> > > Well, that could be. Perhaps the packaging "insight" I had wasn't
> > > inspired :-). I was thinking that from the crypto-ignorant point of
> > > view, they seem quite similar. A SHA256 hash can be seen as a digital
> > > "signature" (or I've heard it called a "fingerprint") of a sequence of
> > > bytes, just as with a public-key signature. Sure, what's going on is
> > > different, but from a utility point of view, it's much the same. This
> > > is why people post md5 checksums of downloadable packages -- it's a
> > > signature.
> > Also a very bad idea. Hashes ensure data integrity, not that it came
> > from the person that you think it came from. As an example, if I took
> Sure. And lots of people use digital signatures in that way, too.
See the above about "bad practice".
> Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> else; I was suggesting that providing easy-to-use APIs to a couple of
> commonly-requested crypto features, for use by non-cryptographers,
> wouldn't be a bad idea.
> Python-ideas mailing list
> Python-id... at python.orghttp://mail.python.org/mailman/listinfo/python-ideas
More information about the Python-ideas