RC4 Encryption Security

[electrochrisso]

How secure is RC4 Encryption?
Wikipedia says not very strong.
Should I use it any more?

[OrangeJuice]

Questions you should always ask yourself beforehand are:

What do i want to use the encryption for?
How important is it to protect the data i want to protect?
Who am I trying to keep out?

That is why there is no easy answer to your Question.

If you want to protect the High scores in your game and not offering a House to someone beating your game, then i would say it is more than enough encryption.

[netmaestro]

AES is much stronger and native to Purebasic now.

[PB]

> How secure is RC4 Encryption?

Strong enough for secure web transactions (banking, eBay, etc) and wireless networks.
Is that sort of strength enough for you? Only you can make that decision. Works for me.

But as netmaestro said: AES is part of PureBasic, and RC4 isn't; so AES may just be the
easier, stronger, solution that you're looking for.

[electrochrisso]

Thanks for the reply to my question guys.
I should have stated the use was for storing passwords, so RC4 might still be ok for that, looking at the output it looks like it would be hard to crack.
netmaestro. I am to learn how to use the AES commands to store a page of text data to a file with a password, then read it back, i would really appreciate it if you could point me in the rite direction to get me started.

May the power of Purebasic grow...

[OrangeJuice]

Traditional, that would be a Job for storing an MD5 fingerprint. This has the advantage that, even if your system somehow gets compromised, an attacker can't get the original passwords because the md5 fingerprint doesn't contain them.

[electrochrisso]

Hi Orange Juice, I am going to tinker with MD5 fingerprint.
Are you saying store each password as a fingerprint or the password used for the encrypted file?
I made a simple password manager that I use to store my passwords as text from the edit gadget and encrypt them with RC4, so I could MD5 fingerprint the password I use to for the encryption, will that make the RC4 encryption a lot more secure?

[netmaestro]

MD5 is excellent for storing passwords because reversing it to retrieve the original text is so difficult as to be considered practically impossible. So basically, you would store the MD5 hash of the password in the executable and when someone enters a password to use the software, you do this test: If MD5(inputpwd$) = reference$... and they get in or not. This way the password text is not findable anywhere in the exe. Its use in this way is ubiquitous in modern computing and very successful.

[PB]

> MD5 is excellent for storing passwords because reversing it to retrieve the
> original text is so difficult as to be considered practically impossible

MD5 is just a hash. It doesn't "store" anything at all, so of course it can't be
"reversed" to retrieve the original text. Am I misunderstanding your comment?

[netmaestro]

Am I misunderstanding your comment?

Yes.

[gnozal]

As I understand it, MD5 has some security flaws.
SHA (also implemented in PB) seems to be more secure.

[PB]

@Netmaestro: I've re-read your post after having dinner and it
makes sense now. Obviously I needed a full belly to think.

> As I understand it, MD5 has some security flaws.
> SHA (also implemented in PB) seems to be more secure.

Yes Gnozal, but where does it stop? RC4 was once fine, and
is now "risky". Then MD5 was fine, and now has flaws. So now
SHA is fine, but... you get the point. Where do we stop? Do
we keep changing the ciphers in our apps every year or two?
This is a rhetorical question, and not having a go at you.

[electrochrisso]

What I have done so far is to use MD5 fingerprint to convert my password into the 32 character fingerprint to be used as the actual password for the RC4 encrypted file. So this should make the RC4 encryption even stronger, i think.
I my new version of my password manager I am going to use AES to encrypt the file and SHA to convert the password into the fingerprint for the key. I will have a bit of fun working out the best way to turn the 40 character long SHA string into 32 byte AES key.
Assuming 32 bytes = 32 characters I chop of 8 characters from the end of the SHA fingerprint string, thats the way I will go for starters, there is probably other and better ways to handle this situation.
There is just so many different ways and options in Purebasic.

[freak]

MD5 is excellent for storing passwords because reversing it to retrieve the original text is so difficult as to be considered practically impossible. So basically, you would store the MD5 hash of the password in the executable and when someone enters a password to use the software, you do this test: If MD5(inputpwd$) = reference$... and they get in or not. This way the password text is not findable anywhere in the exe. Its use in this way is ubiquitous in modern computing and very successful.

There are many databases around the internet though with MD5 hashes and strings that generate them. So if somebody knows the hash and has some luck, he can get a string which will generate the same hash and therefore be accepted as a password too. This is especially true if the password is something common, like a word from a dictionary. This is not the weakness of MD5 though. This is a common brute-force attack.

Yes Gnozal, but where does it stop? RC4 was once fine, and
is now "risky". Then MD5 was fine, and now has flaws. So now
SHA is fine, but... you get the point. Where do we stop? Do
we keep changing the ciphers in our apps every year or two?
This is a rhetorical question, and not having a go at you.

Every year or two is very much an overstatement. MD5 was created in 1991, and the first theoretical weakness was found in 1996 but it took until 2004 until the first practical attacks were published. That is quite a long time in the computer world.

Btw, the flaws in MD5 (and also similar ones in SHA-1) only concern things like digital signing of documents, where the attacker wants to specifically generate two documents with different content but the same hash. Then if he gets one of them digitally signed, the signature will also be valid for his other document. For this there are very fast algorithms today, making MD5 useless for digital signing.

This however does not mean that given an MD5 hash, you can easily guess the original content. As i said above, the only attacks for that are brute-force attacks (with large databases for look-up). So the way MD5 is used in many places to store passwords is still pretty safe. It always depends on what you want to do weather such weaknesses are an actual problem or not.

What I have done so far is to use MD5 fingerprint to convert my password into the 32 character fingerprint to be used as the actual password for the RC4 encrypted file. So this should make the RC4 encryption even stronger, i think.

That doesn't help one bit. The RC4 weakness is that you can reconstruct the key from looking at the data stream. Wether that key is the result of some earlier hashing or a direct password makes no difference. If you can collect enough encrypted data, you can get the plain text.

AES should be preferred over RC4. There are no working attacks against it yet, and by using a 256bit key you can pretty much eliminate the chance for a successful brute-force attack.

[nco2k]

you shouldnt be afraid of the so called rainbow tables, as they become only useful when the password's hash is accessible and if someone can obtain your password's hash, you probably have a much bigger problem to deal with first.

however, most people i saw creating a password hash, just did a simple:

Code: Select all

Hash$ = MD5Fingerprint(@Password$, StringByteLength(Password$))

which is just wrong/insecure and chances are high that such a hash is already listed somewhere in a database. but i never saw a database containing hashes of complex passwords anyway, thats why you should write your own routine to strengthen a password and create a super-hash:

Code: Select all

Procedure$ SuperHash(Password$, Salt$="", MaxLength=32)
  Protected Hash1$, Hash2$, Hash3$
  
  If Salt$ = ""
    Salt$ = "Z0#nXt_37!*yt93r"
  EndIf
  
  Hash1$ = RSet(Password$, MaxLength + 1, "/")+Salt$
  Hash1$ = SHA1Fingerprint(@Hash1$, StringByteLength(Hash1$))
  
  Hash2$ = LSet(Password$, MaxLength + 1, "\")+Salt$
  Hash2$ = SHA1Fingerprint(@Hash2$, StringByteLength(Hash2$))
  
  Hash3$ = Hash1$+Hash2$+ReverseString(Salt$)
  Hash3$ = SHA1Fingerprint(@Hash3$, StringByteLength(Hash3$))
  
  ProcedureReturn Hash3$
EndProcedure

Password$ = InputRequester("Password", "Enter Password", "")
If Password$
  Length = Len(Password$)
  If Length > 3
    If Length < 33
      
      If SuperHash(Password$) = PeekS(?Hash, 40); password is test
        Debug "Password correct"
      Else
        Debug "Password incorrect"
      EndIf
      
    Else
      Debug "Password too long"
    EndIf
  Else
    Debug "Password too short"
  EndIf
Else
  Debug "Password field empty"
EndIf

DataSection
  ;this is just an example.. never store the hash as an unencrypted string!
  Hash: Data$ "aa2420e2c79fbda80930f873a471ed13a7009380"
EndDataSection

but as long as the password/hash/whatever is stored in the same executable, everything is breakable!

oh and speaking of aes, aes192-256 has more weak spots in its key expansion by design, than aes128 and is therefor weaker in theory, which is quiet ironic.

but you shouldnt worry too much about that stuff anyway, just write some clever routines to use its potential to the fullest and everything will be fine.

c ya,
nco2k