As David Wagner points out, encryption with a public key (for which the private key has been discarded) would seem to work.
I think there is a bit more to be said about requirements though. For a one-way encryption algorithm to be injective will also require that the output (nee ciphertext) be at least as long as the input, so unlike a hash function, you can't have a fixed length output for a variable length input (unless the fixed length is larger than the largest input.) One can always invert an injective one-way function by exhaustive search, but do you have a requirement for how difficult it must be to discover the inverse function? If, for example, a public key encryption is used, with the private key thrown away, then we might estimate the work involved in cracking the system. If you want the exhaustive search to be the easiest way to solve the system, then the effective key length of the public key must be at least as large as the message. If the system is to be used for password encoding (as is traditional) then one should also protect against dictionary attacks (precomputation of likely passwords). The usual way to do that is with salt, but if you also wish to avoid someone cracking the whole system, then the encryption key should be generated independently for each encryption and packaged along with the ciphertext. That solves the salt problem and the cracking the system problem in one step. -Larry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]