1

Basically what the title says. If I have a password, of say "APPLEPIE" is it safe to use "APPLEPIE" as the key when I RC4 it? Is it possible to break the RC4 encryption when you know the Key and Plaintext or are short and the same?

Byron Fergo
  • 35
  • 7
  • And how would you decrypt it? – President James K. Polk Nov 01 '13 at 20:43
  • I don't understand that second sentence; if you know the key, then there is very little reason to "break the RC4 encryption". – Maarten Bodewes Nov 02 '13 at 12:19
  • @GregS I don't understand, same way it was encrypted. This is for access to a PIC chip. I have a password such as the example above, I then RC4 the password with itself. Such as: messtoEncrypt = toArray("MyPassword") key = toArray("MyPassword") rc4 = new ARC4(key); rc4.encrypt(messtoEncrypt); base64String = messtoEncrypt – Byron Fergo Nov 04 '13 at 13:42
  • @owlstead For must people yes, however there is always a reason for something. If I ever forget the password, and I know the Key and plaintext where the same, is it possible to decrypt it from only knowing that. – Byron Fergo Nov 04 '13 at 13:46
  • ah; this is the pseudo-code you were talking about. Yeah, if it looks like this, brute forcing it is definitely the easiest approach. That should be trivial. You might be able to crack it faster than you could type it… – Rob Napier Nov 04 '13 at 14:42
  • (That last bit is a joke; it'd probably take hours, but probably not too many on a decent multi-core.) – Rob Napier Nov 04 '13 at 14:53

1 Answers1

2

This should be handled with a key generation algorithm like PBKDF2, which will allow you to securely generate a hash from your password in a way that is appropriate for password verification (which is what I assume you're doing).

While it is possible to generate a system by which RC4 would be safe this way (by converting the password into an RC4 key using a good KDF (such as PBKDF2), and then generating a random nonce), this is a lot of overhead to no purpose. You'll wind up with a much longer final cipher text for the same level of security, and it'll take you longer to generate it. In the end, you'll have just created an extremely complicated secure hash function (whose first step is "do the only thing you needed to do anyway). And you'll probably have made a mistake along the way, making the system insecure. RC4 can be tricky to do correctly and has known related-key attacks; hence the break of WEP.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • Thank you for your answer, this will be inside a secure location so the encryption does not need too be perfect. I was just wondering if using RC4 the way I had mentioned has a weakness where I can find the plaintext, knowing the key and plaintext where the same. See Pseudo code above. – Byron Fergo Nov 04 '13 at 13:50
  • It depends on how you're making use of RC4. If you use RC4 correctly, then no, it is reasonably protected. However, if you use RC4 correctly, this is a very over-complicated solution. The first step you need to do is run a KDF (like PBKDF2). At that point, you've achieved the goal. Adding RC4 at that point can only reduce the security of the system. If you skip the KDF and instead use RC4 incorrectly, then yes, this system provides poor security. The fact that you're encrypting the password with itself only makes it worse, but it would be insecure even with that. – Rob Napier Nov 04 '13 at 14:03
  • In an attempt to be completely clear: Using RC4 this way is less secure than simpler solutions. No encryption algorithm should be used this way, but of encryption algorithms, RC4 is a particularly bad choice because it has well known related-key attacks. You want to hash your password. Use a hash algorithm. I recommend PBKDF2 for this purpose. – Rob Napier Nov 04 '13 at 14:08
  • As you can see from the Pseudo code I would be using it incorrectly I believe. However I am not really worried about that, What I am more interested in is because it is weak, and because RC4 is basically an XOR implementation, is a method possible for me too use that in the case I forget the password, can I recover it only knowing what I know. Key and Plaintext are the same, both are short, and the only thing done too it after Rc4 is Base64. So I just decode the Base64 and I have the raw output. See what I mean? – Byron Fergo Nov 04 '13 at 14:11
  • (You didn't post the pseudocode) If you want it to be crackable, why not just use a simple obfuscation? ROT-13 it or Base64 encode it. Why use RC4 if you just want obfuscation? If you want it to be super-secret obfuscation, just ROT-10 it or Base60 encode it (i.e. change the value to some "super secret" number). Or are you trying to break an existing system that's poorly implemented? If the password is reasonably short and type-able, just brute force it. I'd probably base it on John the Ripper's code like this guy did: https://github.com/kholia/RC4-40-brute-pdf/blob/master/RC4-40-brute.c – Rob Napier Nov 04 '13 at 14:39
  • Encoding isn't exactly what I am looking for, however I may end up doing just that. It is based on an existing system however I have all the code and methods etc because I want to see about an update while proving the current system insecure. The current system can handle a password up too 31 characters, however the one in use right now is a 9 char pass that is all the same case A-Z only. So very weak. I will look into the link you posted, thank you. – Byron Fergo Nov 04 '13 at 14:53