4

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).

Blankman
  • 259,732
  • 324
  • 769
  • 1,199
  • 4
    You can't encrypt something without a key. If there's no key, either anyone can recover the plain-text, or it is unrecoverable to everyone. – erickson Jun 04 '09 at 17:43
  • 12
    public string encrypt(string msg) { return "secret!!"; } – Juliet Jun 04 '09 at 17:45
  • 1
    @Princess: public string decrypt(string msg, string realmsg) { return realmsg;} // Decryption is even easier! – belgariontheking Jun 04 '09 at 17:48
  • @Princess Well, he never said he needed to decrypt! – Chris Marasti-Georg Jun 04 '09 at 17:51
  • 1
    @Princess: I think that should be your getKey() function. :) – Bill the Lizard Jun 04 '09 at 17:53
  • 6
    +1 - I think that it is a fair question to ask if you dont know the answer = thats what this site is for. People who voted this question down: boo. – Shane C. Mason Jun 04 '09 at 18:06
  • Encryption algorithms are _tools_ used to mitigate _vulnerabilities_ to specific _attacks_. No one can possibly recommend the right algorithm to you if you do not tell us what are the vulnerabilities and attacks you are worried about. So: what are they? – Eric Lippert Jun 04 '09 at 20:02
  • 2
    I agree with Shane. Like Jeff Atwood has said, the only dumb question is the one that someone just answered. This is a legitimate question for a noob. Or maybe it's like boat programming. Either way, it could help someone who's just starting out. – erickson Jun 04 '09 at 20:55
  • Isn't "hash" encryption without a key? – Pithikos Dec 19 '12 at 13:08

8 Answers8

16

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.

Community
  • 1
  • 1
Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
  • Mac OS has its `keychain`, which is similar. Does anyone know of something like this for Linux, or more specifically RH AS 5? – erickson Jun 04 '09 at 20:57
8

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.

Welbog
  • 59,154
  • 9
  • 110
  • 123
6

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.

Jherico
  • 28,584
  • 8
  • 61
  • 87
4

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

belgariontheking
  • 1,351
  • 1
  • 10
  • 15
  • 7
    @belgariontheking: The 13 is something you need to decrypt it. Just because it's hardcoded into the rot13 algorithm doesn't mean it's not a key. – Welbog Jun 04 '09 at 17:41
  • 1
    I would hardly call rot13 "encryption" – rlbond Jun 04 '09 at 17:45
  • @rlbond me neither, but all of the "you can't do it" answers were taken, so I went for a "YOU CAN DO IT" answer – belgariontheking Jun 04 '09 at 17:52
  • BTK is right, ROT-13 is a keyless algorithm. The user of the software doesn't need to know the key or even what the process is that's being used to encode/decode the data. – Bill the Lizard Jun 04 '09 at 18:00
  • @Bill: not entirely correct. It uses a key, but that key is built into the algorithm. It could just as easily be rot12-14, but that wouldn't be a symmetric key like rot13. 13 just happens to be convenient that way. In Greek, it would be rot10. Welbog is correct, which is why I edited my response. Now, if you want to talk about /effective/ encryption, that's another thing entirely. The point of all this the subtle difference between being a keyless algorithm and an algorithm where everyone already knows the key. – belgariontheking Jun 04 '09 at 18:08
  • 1
    @BTK: You were right the first time. The 13 in ROT-13 isn't a key if you build it into the algorithm. A key is something separate from the plaintext, ciphertext, or algorithm. As you said before, if you implement it as ROT-X and make the user provide X, then it is a key. – Bill the Lizard Jun 04 '09 at 18:09
  • 1
    @Bill: The concept of a "key" is more abstract than you'd like to acknowledge. Accepting the rot13 algorithm as a black box, the very idea that you need to use the rot13 black box to decrypt a message it creates is itself a kind of key. – Welbog Jun 04 '09 at 18:17
  • @Nyy: bzt fgsh nobhg ebg nf n inyvq rapelcgvba zrgubq ng nyy – Frakkle Jun 04 '09 at 18:19
  • @Senxxyr: V pna'g! V'z fghpx va gur arkhf bs ebg13! Naq vg'f nyy lbhe snhyg! – belgariontheking Jun 04 '09 at 18:21
  • 2
    @Welbog: A key is separate from an algorithm. A black-box algorithm does not itself constitute a key. http://en.wikipedia.org/wiki/Key_(cryptography). If my encryption algorithm is to shuffle the bytes of a message in a way that only I know, and my decryption algorithm is to reverse the steps of the shuffling, that's not a key. ROT-13 is just a very simple instance of this same process. – Bill the Lizard Jun 04 '09 at 18:30
3

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...

Arjan Einbu
  • 13,543
  • 2
  • 56
  • 59
2

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.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
  • 2
    The system was not "rendered useless"; it was still perfectly useful for the purpose that it was designed for. Preventing determined attackers from decoding was not one of our design goals when we designed it. We knew it would be broken on day one. The goal of the system was to force people who wanted to steal script source code to have to use a decryption tool. That they would have to deliberately use a decryption tool demonstrates malicious intent, which could then be prosecuted. – Eric Lippert Jun 04 '09 at 20:02
  • @Eric: I stand corrected. From the site, "Note that this encoding only prevents casual viewing of your code; it will not prevent the determined hacker from seeing what you've done and how." – Bill the Lizard Jun 04 '09 at 21:12
  • 1
    Ultimately, whether the encoder was a good idea or not given (1) the impossibility of strong encryption for a scenario where the source code is compiled at runtime by user-mode code, and (2) the legal questions about whether the proposed evidence of purported violations of "do not reverse-engineer" contracts is admissible in court, is certainly a debatable point. But our customer research showed that many customers badly wanted this functionality, even as they were aware of its shortcomings. So we implemented it. – Eric Lippert Jun 04 '09 at 21:54
  • @Eric: Thanks for clarifying these points for me. The legal issue is an interesting one. – Bill the Lizard Jun 04 '09 at 23:21
2

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.

David Thornley
  • 56,304
  • 9
  • 91
  • 158
1

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.

chris166
  • 4,769
  • 4
  • 24
  • 25