CTO <debatem1@gmail.com> wrote:
On Sep 21, 11:43 am, Bill Janssen <jans...@parc.com> wrote:
CTO <debat...@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. And, by the by, hashes are often used for purposes other than message integrity, outside the sphere of crypto.
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. 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. Bill