136 reputation
5
bio website
location New Jersey
age 18
visits member for 1 year, 8 months
seen Jan 16 '13 at 4:43

Aug
26
comment Is there a way to make RC4 (ARCFOUR) secure, or is it completely broken?
whoops, I got so caught up with RC4 and having to combine the IV and key that I didn't catch my mistake. With AES, I don't even have to re-key the message after each packet, because updating the IV does not require the key to be updated. this should mean i wouldn't have to deal with the AES key scheduler more than once. Thanks for the info anyway!
Aug
26
comment Is there a way to make RC4 (ARCFOUR) secure, or is it completely broken?
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.
Aug
26
comment Is there a way to make RC4 (ARCFOUR) secure, or is it completely broken?
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!