Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Encrypting Largish Files

by IndyZ (Friar)
on Sep 23, 2001 at 23:53 UTC ( #114207=note: print w/replies, xml ) Need Help??

in reply to Encrypting Largish Files

Also, I assume that when they say "key", they're refering to the password of x length. I.E. "myPassord123" would be a key 11 bytes in length???

"myPassord123" (sic) would actually be a 12 byte key (it has twelve characters). The real problem is that by using only the characters available on your keyboard, and by using english words, you are making a brute force attack on your encrypted data a relatively easy task. You should choose a truely random key generated from your systems entropy pool and then processed further (via a hashing function, possibly) to make it more random and secure. The Crypt::Random module can generate cryptographically secure random numbers (keys) for you.


Replies are listed 'Best First'.
Re: Re: Encrypting Largish Files
by John M. Dlugosz (Monsignor) on Sep 24, 2001 at 08:48 UTC
    The passphrase length in RC4/CyberSaber doesn't have anything to do with the final key length. In fact, RC4 doesn't really have a "key" in the obvious sence the way block ciphers do.

    Rather, the internal state is an array of 256 bytes, one holding each value, that is shuffled into some permutation. The input letters of the passphrase control the shuffling details.

    So, the actual "strength" of the cipher is that it has 256! possible states. So, the "key" is approximatly 1683 bits, since there are 2**1683 possible states for the cipher to be set-up into.

    If you know something about how the passphrase is chosen, then an attacker can search far less than that many possibilities. E.g. with 96 ASCII chars and 8 char length, only 96**8 or 2**52 of the possible keys will ever be used. In order to say the system has an effective key size of 52 bits, the attacker would have to know that, and know which 2**52 keys are available. That's the case with "40 bit" SSL.


      Just for clarification, could you explain your math. How do you get from 256 states to to 1683 bits as 256 * 8 = 2048?

      Also, when you say "only 96^8 or 2^52" how are these two equivalent as 96^8 = 7.21e15 and 2^52 = 4.5e15 or did you mean something different?

      I'm only asking because I'm just starting to learn about cryptography..

      As a side note, how long does it currently take to brute force your way through 4.5e15 keys using non-military strength computers. (assumes that hackers have only consumer to academic calibur machines.)?
      Filmo the Klown

        256! (factorial), not 256*8. Start with the list 0..255 and shuffle it. That list is 2048 bits long, but you will never have, for example, two bytes both containing 42. So the number of legal states is smaller than the number of states that this much memory can represent.

        7.21e15 vs 4.5e15 : within a factor of 2 (1 bit). Fractional bits don't count, so round down. 2^52 is a little small, but 2^53 is too large.


Re: Re: Encrypting Largish Files
by willdooUK (Beadle) on Sep 24, 2001 at 14:35 UTC
    "Passord" isn't an english word ;)

    My co-worker told me about a program he wrote in his hacking days which tried a brute force assault on a server over http, giving a name and password from a list of first names.

    Apparently a lot of people use their first name for both their username and password - so all you need is a list of popular first names....

    How about hard-coded passwords - can anyone comment on the security of having an admin password written into a cgi script?

    I put an admin section into a site, which is based around a single cgi script. The password for using the admin controls is held as a scalar in the cgi code, and I'm hoping thats pretty safe (because the server will always execute that script and not list it to the browser). Am I fooling myself?

    "Home is a castle you built in my mind; I'm home anywhere, anytime."
    Donny Hathaway
      You're probably fooling youself a bit... The first stage in almost any cgi exploit is to find a way to read the source code. There are lots of ways to do this, but a classic one is to use one insecure CGI to read the source of another. I frequently get entries in my access_log that look like this:
      If the author of some.cgi wasn't careful, its possible that some.cgi will spit back the source to someother.cgi.


Re: Re: Encrypting Largish Files
by filmo (Scribe) on Sep 26, 2001 at 20:53 UTC
    I don't know if I'm clear on the concept. If you let the program choose a randomly large key (eg '23klsd9fjlsd09u3asdljf0' plus a few non-keyboard entries...) and then encrypt the file and send it off site to another location, how do you obtain that automatically generated key for decryption when needed in the future.

    Remember, the original purpose of this was to encyrpt mySQL dumps on a daily basis and send them offsite for backup purposes.

    If it involves sending the key to the backup site, then I'd need a secondary encryption system such as PGP to send the keys securly, in addition to a way to tie each unqiue key with each unique data file. Murphy's Law says that when you try to decrypt one of 365 daily files in a year, its going to be that days key that you've misplaced.

    It seems to me for this to be practical, you would want to avoid having to track randomly generated keys to try and decrypt your files at some future date. My limited understanding is that Public key encryption is much more processor intensive than private key encryption so this is also a concern given the large size of mySQL dumps and the possiblility of simply PGPing the mySQL dump.
    Filmo the Klown

      Partially right. PGP uses private (symetric) key encryption for the data and public (asymetric) key encryption for the secret (symetric) key. Clever guy that Phil, eh?

      alex pleiner <>
      zeitform Internet Dienste

        Zimmerman deserves his plaudits, though this one might be a bit misguided... It was actually Whitfield Diffie and Martin Hellman that came up with the concept of asymetric keys... Ron Rivest, Adi Shamir and Len Adleman (RSA) get credit for finding a mathematical algorithm that is suitable for this purpose. And Phil Zimmerman deserves credit for implementing the algorithm in code, and for the balls to release it openly in spite of the government and RSA breathing down his neck.

        For further information I'd recommend Simon Singh's The Code Book.


      If you want to use the same key every day, you can randomly generate the key, and then move it via a physical medium between locations, or just move the key with PGP (once). With some algorithms, this will make you more vulnerable to an attack. Using a different key everyday is similar to a onetime pad system. It will probably be the most secure option because if the attacker breaks one days key, he will have to start over from scratch for every other day. If they break the PGP key that you are using the transfer the daily key, however, they will be able to read all of your one time keys. Asymetric (public/private) keypairs probably aren't necessary, since you shouldn't have to give out either key. It could be a good idea though, since if your server (with only copy of the public key) is compromised, the archives will still be safely encrypted.

      Cryptography is a complicated science that I don't personally feel qualified to make a specific recommendation about. For a good overview of different cryptographic techniques and algorithms, go get a copy of Applied Cryptography by Bruce Schneier. It's quite good, especially if you like books with source code included.

      Now, let's think simpler: The real question here is how secure does your data have to be? If absolute security is a must, the don't send your data over the internet at all. Put it onto DATs and hire a courier to transport it for you. You might also want to consider a VPN, which will automatically encrypt all traffic over a network link. Your server must be secure also. If the attacker can get into the server and steal the unencrypted data, there is no point in encrypting it first.

      Wrap up: Sorry that was so long a rambling. Remember, your server must be secure first. Think simple, but secure. Physically moving the medium is more secure than emailing or ftp'ing it. If your data is that important to you (credit card numbers, social security numbers, bank transactions), hire a professional who has experience in this field.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://114207]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2022-08-14 09:49 GMT
Find Nodes?
    Voting Booth?

    No recent polls found