Encryption algorithms that don't use a key

Question

Hi,

I need a simple encryption algorithm that doesn't use a key.

Which ones do you guys recommend?

How about if I use the built in encryption method that forms authentication has? (I forget the method/namespace for it).

Answer 1

Something outside of the thing being encrypted needs to be used to do encryption, if only because you need that thing to decrypt it later. This external thing is a key. There is no useful encryption without a key. There is only hashing.

Answer 2

rot13 uses a key that's already in the algorithm. That's the closest I think you're going to get.

Answer 3

What you are calling encryption is simply obfuscation. Even then its going to be encryption where the key is embedded in the algorithm. You'll have to provide at least a simple use case for this before you're going to get any kind of reasonable answer.

Answer 4

Every symmetrical encryption scheme has a key. If you're looking for an encryption scheme where you don't manage the key, you might look into the Data Protection API, exposed in .NET (2.0 and above) as the System.Security.Cryptography.ProtectedData class. It provides symmetric encryption of arbitrary data, using the credentials of the machine or (better) the user, as the encryption key.

byte[] plaintextBytes = GetDataToProtect();
byte[] encodedBytes = ProtectedData.Protect(plaintextBytes
                                            , null
                                            , DataProtectionScope.CurrentUser);

See my other answer here for more detail.

Answer 5

The problem with keyless encryption is that once it's broken, it's broken for everyone. Take MicroSoft Script Encoder as an example. Once one person figured out how to reverse the encryption and published it, the encryption was broken for everyone (see comments for details on how this isn't as bad as it sounds in this case).

That being said, you can use any keyed algorithm and keep the key a secret and you'll get the same (bad) effect.

Answer 6

Fundamentally, ciphers are a way to let Alice tell something to Bob that Eve can't figure out even if she overhears.

This means that there has to be some way for the ciphertext to distinguish Bob from Eve.

Usually, this is a key. Nowadays, it can be a symmetric cipher key that Alice gives to Bob and not Eve somehow, or an asymmetric cipher key that Bob broadcasts so that anybody can encrypt a message for him that only he can read (often used as a way to transmit a symmetric cipher key).

An algorithm can serve as a key, but algorithms are really inconvenient to distribute and keep secret. It's better just to use a standard key.

You could simply obfuscate the plaintext, if you're willing to count on Bob being motivated to read the message and Eve not be. You could do that by zipping a file, for example. Eve couldn't just read it, she'd have to unzip it. This is usually done to prevent Eve from accidentally reading something meant for Bob, on the assumption that Eve is honorable but may make occasional mistakes. The example popping into my mind is the CVS password file; it will prevent a sysadmin from seeing the password at a glance, but it's "the moral equivalent of rot13" if somebody actually wants to read it.

So, to give you a useful answer, we need to know what you want to use this for. How sensitive is the data? How likely is it to fall into unfriendly hands? Who do you want to be able to read it?

BTW, never roll your own cryptography. It's real easy to get something wrong and real hard to notice it. Use standard implementations of standard algorithms.

Answer 7

As an aside to the talks about no key = no encryption...

Maybe what you're really after is automatic and safe key creation and exchange with no user interaction. This can be done by the use of asymmetric encryption, and it works like this:

Scenario: A needs to send a message to B, and wants to make sure no man-in-the middle can read the message.

A and B initiate a conversation like this:

1. A asks B for B's public key.
2. B generates a public/private key pair, and sends the public key to A.
3. A uses the public key to encrypt the message, and sends the message.
4. B receives the message, and decrypts it with its private key.

This works since the message is encrypted with a public key, can only be decrypted with the corresponding private key. So the public key doesn't have to be secret. If man-in-the-middle picks up the public key, he can't use it to decrypt the message.

You'll probably find tons of information about this if you google for asymmetric encryption...

Answer 8

If you're really after obfuscation, you can use the PasswordDeriveBytes class to create a key from a password. Then use the key in e.g. AES.