(Rapidly moving off-topic)

--On 11 February 2006 18:48 +0000 Ben Laurie wrote:

>>> Also, FWIW, hash algorithms are perfectly usable as encryption
>>> algorithms.

>> Pardon?

> I didn't say you could decrypt a hash function, I said you could use one
> for encryption.
> The construction is known as "Chaffing and Winnowing", was invented by
> Ron Rivest, is hugely inefficient and was designed to show the
> foolishness of crypto export laws.

This is merely a semantic point (meaning of the word encryption). Even the
author of the paper explicitly describes both stenography and chaffing &
winnowing as "not employ[ing] encryption".

>From the paper:

There are two major techniques for achieving confidentiality: ...
Stenography ... Encryption ... This paper introduces a new
technique, which we call ``chaffing and winnowing''
Then: "Winnowing does not employ encryption"

His perfectly adequate definition of encryption is:
Encryption: transforming the message to a ciphertext such that
an adversary who overhears the ciphertext can not determine
the message sent. The legitimate receiver possesses a secret
decryption key that allows him to reverse the encryption
transformation and retrieve the message. The sender may have
used the same key to encrypt the message (with symmetric
encryption schemes) or used a different, but related key
(with public-key schemes). DES and RSA are familiar
examples of encryption schemes.

A hash function doesn't do that. Chaffing & winnowing doesn't do that. The
hash/MAC function is just a component of the algorithm here, and is no more
an "encryption" function here than when (say) it is used to produce a
private key from a secret string. If we go this way, addition could be
described as encryption on the basis it's used in just about every
encryption algorithm. The key thing he's doing is adding chaff, PLUS the
original plaintext (wheat), giving a range space FAR larger than the
original domain (as is the case in stenography, under whose bracket
one might argue this technique actually falls).

(and back on topic)

And whilst indeed the point he is making (well) is that that crypto export
laws are dumb, he himself says:

We have the transformation of appending a MAC thus:
packet --> packet, MAC
The packet is still ``in the clear''; no encryption has been
performed. We note that software that merely authenticates
messages by adding MACs is automatically approved for export, as it
is deemed not to encrypt.

So at least this generation of dumb crypto laws do not cover MAC (hash)
functions, which is what was, I think, the original question. Unfortunately
pointing out laws are dumb does not allow us to ignore them.


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.