Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I need a method to authenticate a process with another in order to establish interprocess communication between them, to prevent malicious processes from trying to hook onto the system. Currently I just send a password in plaintext between the two processes and the host process just performs a string comparison with its copy of the password, and will disconnect the connecting process if they don't match. It was fine when I was limited to connecting each process on localhost, but obviously this is not secure if someone just happens to have access to a network between each process and could sniff the packets. Do note that I only care about encryption for the password exchange and I don't really need it to secure the communication.

So basically I need a encryption algorithm that doesn't need to protect its contents well but does need to protect its key, and needs to be as fast as possible with minimal RAM usage and I/O overhead. Yes, data exchange is more CPU-bound than I/O bound since the two processes will be doing loads of calculations and they most likely will be connecting through localhost. Now, I came across RC4, which has a throughput of over twice that of AES-128, but it is evident that it has some weaknesses and I have a lot of questions about how to implement it in a secure way.

Well first question - it's in the title. Is RC4 completely broken and should be avoided? I hear a lot of "it is secure if properly used" and then a lot of "use of RC4 is discouraged."

I was planning to keep the plaintext password on both processes and have them SHA-224 hashed, and concatenate the hash with a 32-bit IV as a 256-bit key for RC4. Are there any security risks with this approach? Perhaps I could then hash the concatenated IV and hashed password with SHA-256? I'm well aware that WEP was cracked because it used a 24-bit IV, but a 32-bit IV has over four billion more unique values. Should I avoid incrementing the IV after each packet like WEP?

And when it comes to RC4-drop[n], what is a reasonable value for n? 256, 512, 768 bytes? How would you implement drop n on a library whose only public operation is encrypting a byte array - pass a byte array of length n after the engine is initialized with the key? Would that mean you would have to basically process n empty bytes after every time you change the IV (which happens after every packet)?

Sources: http://www.rsa.com/rsalabs/node.asp?id=2009

EDIT: after reading all these excellent responses, I realized how ignorant I sounded about the whole subject. I had no experience with cryptography before this day, and I only was able to read about RC4's risks from the limited Google results that I could barely follow. thank you to everyone who has been patient with me!

Correct me if I'm wrong, but I believe a better solution is to either use AES (which is not slower because re-keying RC4 after each packet is expensive) or an universal message authentication code. I can easily work with AES, but my understanding of MAC is a bit shaky. An IV is only secure if the update sequence is randomized and unpredictable, meaning I would have to send a 128 bit IV for every message that is sent, which can add a 400% overhead to the short, 4 byte packets that are commonly sent by my application. HMAC can add more than twice that amount if SHA-256 is used. I am going to have to investigate this matter further.

share|improve this question

migrated from security.stackexchange.com Aug 25 '12 at 14:05

This question came from our site for Information security professionals.

    
It's not black and white, that it's secure or completely broken. However, RC4 is stream cipher and it's considered weaker then block cipher like AES. –  Andrew Smith Aug 25 '12 at 13:08
4  
@AndrewSmith the way you put it implies stream ciphers are intrinsically weaker than block ciphers... this is not true, they just have different pros and cons. –  Thomas Aug 25 '12 at 13:44
    
IMHO stream cipher is weaker because it's very easy to crack it with dedicated hardware, as stream cipher is designed to be hardware-friendly, but also thru software it's easier than with block cipher. Actually, this is how video encryption works, and this is one of the key methods in piracy to bypass it. This is especially true for satellite transmission layer encryption, were weakness of stream ciphers is widely exploited by governments and pirates. On the other hand, using AES is considered much safer to use over the air transmission. This is big difference for business. –  Andrew Smith Aug 25 '12 at 13:57
2  
@AndrewSmith There is no reason to consider stream ciphers intrinsically weak. They require nonces(IV must not be reused) and they're malleable. But when used correctly they're perfectly fine. You can even turn a block cipher into a stream cipher by using CTR mode. –  CodesInChaos Aug 25 '12 at 14:14
2  
@AndrewSmith That article only talks about weaknesses in RC4, not weaknesses in general streamciphers. You make it sound like stream-ciphers in general are weaker than block-ciphers. They're less flexible, but not weaker when used correctly. –  CodesInChaos Aug 25 '12 at 16:01

2 Answers 2

up vote 16 down vote accepted

A few observations:

  1. RC4 suffers from related key attacks. This means your idea of concatenating a 224 bit key and a 32 bit IV is not a good idea. You should rather use $\operatorname{SHA-256}(Key||IV)$

  2. Remember that a (Key, IV) pair must not be reused, ever.
    A 32 bit IV can work if it's a counter, but IMO such a scheme is unnecessarily fragile. I'd rather generate a new, random 128 bit value for each encryption.

  3. Even with dropping, RC4 is still a bit biased. This can allow password recovery if an attacker can observe a few billion communications.

  4. You don't protect data integrity. For example an attacker might keep the encrypted password intact, but change the rest of the message. I don't understand your problem well enough to know if that's a problem.

  5. There might be replay attacks, where an attacker repeats an earlier message fully or in part.

  6. Your assumption that RC4 is faster than other ciphers isn't necessarily true. On many modern systems AES is really fast. There are also other modern stream ciphers, such as Salsa20 which are fast and much stronger than RC4.
    RC4 has costly initialization. So its only fast if you need to initialize it rarely. In particular if you reinitialize for each packet, its performance will certainly drop below AES.

  7. Do you really need a cipher in the first place? You might be better off with a MAC. It seems like you're interested in authentication, not confidentiality. Universal MACs can be really fast.

  8. User Passwords often have low entropy, so you need to strengthen them before using them as a key. Strengthening them is computationally expensive, and is done using KDFs, like scrypt or PBKDF2.
    Consider using a high entropy key instead of a password.

  9. If you use a constant key hardcoded into an executable, those executables may never run on untrusted machines. Else an attacker could simply extract the key out of the executable.

In short:

  1. The weaknesses in your protocol are likely much more severe than the weaknesses in RC4.
  2. There is little reason to use RC4 in a new protocol. There are fast and strong alternatives.
share|improve this answer
1  
I think that answer has quite a bit of entropy for "A few observations" :) –  owlstead Aug 25 '12 at 16:13
    
Thanks! Your response was very 'noob' friendly and I have gained the understanding that 1.) re-keying RC4 after each packet will make it slower than AES, 2.) I should not use one iteration of a hash on a password as a key. I will probably avoid MACs and use encryption instead because it adds no size overhead. As for a key, do you think running a 128-byte array through a pseudo random number generator, and storing the generated value on the server and clients as a key for AES-128 will do the trick, or is this insecure in some way? I don't want to choose 128 values between 0 and 255 by hand! –  Kevin Jin Aug 26 '12 at 2:55
    
oh, and I plan on deploying each process that communicates on this protocol on systems that I administer and that only I have access to. if the key was leaked, hackers could phish the passwords of users who connect to my set of processes, but I would have much bigger problems if they were able to hack into my servers to find the plaintext key on my filesystem. –  Kevin Jin Aug 26 '12 at 3:01
2  
@KevinJin, I think you should ask a separate question for those issues. But really, my recommendation is: don't do any of those things. Instead, use TLS. It will provide a secure way to establish a secure connection between the client and server. –  D.W. Aug 26 '12 at 3:32
    
I would point out initial key expansion for AES is also quite slow compared to other block ciphers. –  ewanm89 Aug 26 '12 at 10:27

No, RC4 is not completely broken. It is possible to use it properly. It's just not very likely that an average developer will do so.

RC4 is not a good choice for new systems. It is tricky to use properly. There are some serious pitfalls which, if you're not an expert cryptographer, can bite you in the butt. In fact, if you take a quick look in the mirror, I think you'll find a few bite marks in your own trousers. :-)

So, some advice, starting with the general and on to the specific:

Don't roll your own crypto stuff. Don't. Just don't. You're likely to get it wrong. Indeed, you did get it wrong. And while you can try to fix up the mistakes you made that you learn about here, the result will probably still be wrong in another way that you haven't thought of, because you aren't aware of the decades of lessons that the crypto community has learned about how to avoid security problems.

Instead of trying to design your own encryption program, you should use an existing well-vetted system. For example, I recommend GPG (or PGP) for file encryption, TLS (or SSL or SSH) for encrypting a connection, or Truecrypt (or Bitlocker or FileVault 2) for encrypting a hard disk, etc.

In other words, if you are asking "What crypto algorithm should I use in the program I'm writing to encrypt my data?", you are asking the wrong question, because in most cases, you shouldn't be writing a program to encrypt your data: you should be re-using existing well-vetted programs.

Don't use poor entropy keys. Your scheme derives the crypto key from a password. This has some severe security problems, and you should avoid doing so if at all possible. If you must do it, learn how to mitigate the risks.

If you used a well-vetted crypto program, odds are that you wouldn't need to worry about this: the designers would have taken care of this for you.

Don't forget to use message authentication. Using encryption without also using some form of message authentication -- as you are doing -- is almost always wrong. You need to use an authenticated encryption mode, or use a message authentication code (MAC) properly, to prevent tampering with the message.

If you used a well-vetted crypto program, odds are that you wouldn't need to worry about this: the designers would have taken care of this for you.

Don't use RC4 improperly. Your post is exactly why people say things like "Don't use RC4" and "Use of RC4 is discouraged". RC4 tempts people to use it in ways that are totally broken. You got tempted and made some of those standard mistakes. For instance, you planned to concatenate the key and the IV. Don't! That's massively insecure. That is exactly the mistake that WEP made, that makes WEP easy to crack. (You said "WEP was cracked because it used a 24-bit IV", but that's not accurate. Current WEP crackers don't rely upon the width of the IV at all.)

If you used a well-vetted crypto program, odds are that you wouldn't need to worry about this: the designers would have taken care of this for you.

Do I need to repeat it again? Use a well-vetted crypto program; don't try to design and write your own. Naah, I think you got the message by now. :-)

share|improve this answer
2  
The temptation of homebrew crypto is certainly strong. It's one of the points where I often disregard my own advice. –  CodesInChaos Aug 25 '12 at 18:03
2  
@CodesInChaos it is extensively preached not to use home grown encryption by Dan Boneh from Stanford University. Then look at SJCL, the Stanford JavaScript Crypto Lib. 2 mayor security advices, one half discovered by me, AAD not covered by authentication tag, and a broken random number generation. I don't know if the prof was involved, but those are major bugs, in studentware (the fact that it is studentware isn't mentioned anywhere. The dark side is strong indeed. –  owlstead Aug 25 '12 at 23:05
1  
@CodesInChaos Doesn't that "dark side" use those weird ciphersabers too? ;) –  e-sushi Oct 5 '13 at 14:20
3  
@e-sushi At the lower level I mostly use NaCl stuff, but at the higher levels I like homebrew stuff, for example designing my own SSL alternative. I don't like TLS or GPG much. I tell people to use TLS, but I don't like using it myself, so I'm a bit of a hypocrite. –  CodesInChaos Oct 5 '13 at 14:25
1  
@CodesInChaos Makes sense. I have my own (probably psychologically motivated) problems with TLS and GPG… though, I'm certainly not confident enough to go ahead and design my own SSL alternative. But hey, that might just be the fine line between noobs like me and (hypocritical #lol) pros like you. Not saying I wouldn't be interested in taking a sneak peek at your homebrew stuff - but that's my curiosity talking... in the end it's probably cryptographically safer to ignore my own curiosity sometimes. –  e-sushi Oct 5 '13 at 14:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.