Re: Which is more secure RC2 or RC4 ?

First of all I'd like to thank everyone for taking the time to read and
reply to my questions, especially for the select few who kept the
metaphors down to a minimum (I mean come on guys, I can understand now
that my original question was that of a total noob, but have some
mercy...)!

While it is true that I am new to cryptography, I do have a fast
learning curve and I can now understand some of the replies to my
original question, since asking if I should use RC2 or RC4 implies a
complete ignorance to the difference between the different kinds of
ciphers (i.e stream/block ciphers), and their advantages/disadvantages
and/or applications.

Since I'm working on a web application in an ASP environment, I'm using
an ActiveX component called AspEncrypt to apply encryption to the
information, and as such I used a lot of the material on the AspEncrypt
website for reference, such as the case with the "saving the key to a
remote place in the registry" example given earlier, which I got from:
http://www.aspencrypt.com/task_creditcard.html

It seemed reasonable, since the registry is so vast, even if someone
were to get a copy of it, it's like finding a needle in a hay stack...
but regardless that really isn't all that secure when you really think
about it.

For the sake of better understanding where I'm coming from, I'd like to
explain in more detail what it is I'm working on exactly so I could get
some better/more specific answers to my questions.

Basically I am working on an web-based online service which allows
users to buy a subscription to this 'service', using a secure online
form (SSL 128 bit) to place the order with their credit card. The user
information is then stored in a database table (e.g Name, Address,
Personal info etc.) on a permanent basis. Whereas the billing
information (i.e Credit card info) is stored on another table in the
same database temporarily, until the order is approved manually and the
credit card has been billed (via 3rd party), at which point the credit
card information is automatically deleted from the database.

Now, what I wish to do is apply encryption to ALL of the information
(whether it's personal or financial) so that in the event that the
database is somehow hacked (the database being MSSQL), the hacker will
not be able to decrypt the information, thereby keeping our user's
privacy from being violated and/or their financial information misused.

Now, obviously there are a LOT of security related issues that arise
when constructing such a system, which go beyond the simple question of
"what cipher should I use to encrypt the data", such as the overall
security of the webserver, and many different overall security
concerns, but for the sake of this discussion I would only like to
address the specific issue of encrypting database information and the
best way to do that, so in the even of the database being hacked, the
information in it would be useless without the correct decryption key.

From what I've read so far I've concluded that the following basic
steps should be taken in order to maintain a good level of security,
please correct me if I'm wrong and feel free to add more suggestions of
your own:

1. The key should never be kept in the same place as the information.
2. It's better to use a more advanced cipher, meaning AES instead of
RC2 or DES etc.
3. The password on which the key is based should always be hashed with
SHA (which offers 160 bit hash size, unlike MD4/5, which is also
considered less secure).

What I want to be clear about is how exactly does a password driven key
work in comparison to a random key.. please see if I got this right:

When decrypting some text using a random key, all you need is the key
itself in order to decrypt the information, whereas when you decrypt
text using a password driven key, having the key is not enough, you
need to match it with the correct password in order for the decryption
to work.

Would that be a correct way of defining it?
(Again, I realize this question may look completely novice, but please
try and keep the answer as direct as possible, so that you can at least
point me on the right direction from which I can advance and gain
deeper understanding of the process)

Also, if the above is true, would that not provide sufficient security,
meaning if I encrypt the information using AES and a password driven
256 bit key?

Another thing I'm a bit confused about is where does the whole one way
hasing of the password come into place... For the sake of argument, In
the most basic example given in the above link, suppose you create a
random key and export it to a file (e.g 'C:\creditcard.key'). Now, you
use this key to encrypt the information, and you use the exact same key
to decrypt it. If someone were to get a hold of that key he would then
be able to decrypt any of the information with no effort.

Let's take this further and now use a password driven key, which is
also exported to a file. In this case getting a hold of the file
containing the key wouldn't be enough, now you also need the password
which was used to create the key in the first place in order to decrypt
the information. Now, if the password is obviously saved somewhere on
the key file then opening the file would reveal it and basically
nullify any password security, but if the password was hashed then the
security is greatly increased (assuming of course that the password is
complex).

Basically I wish to understand where exactly is a password stored, so
when you enter it to decrypt information the machine has to compare
what you entered to the original password used to create the key.. so
where is that original password stored? Is it a part of the key itself?
And so by hasing it would that not provide adequate security?

.

Relevant Pages

  • Re: Application security question
    ... you want to implement security. ... So you are protecting the database from direct querying and altering ... login credentials for the database from the application. ... Why encrypt the password? ...
    (comp.lang.java.programmer)
  • Re: Encryption of files on USB flash drive
    ... You can find problems with current transparent security methods, ... It is an EFS that encrypts individual files. ... You can choose to encrypt a folder and all of it's contents (including ... encrypt and decrypt data. ...
    (sci.crypt)
  • Re: How to prevent importing tables
    ... why in-built encryption doesn't even matter if they otherwise have ... off-topic but is all to do with security and "extraction". ... > sufficient permission to open the database, ... then they don't even need to decrypt it! ...
    (microsoft.public.access.security)
  • Re: SSN encryption
    ... >> We want to encrypt social security numbers in a database. ... address and SSN are always excluded. ... exposed if there were a breakdown in the other security precautions. ...
    (sci.crypt)
  • Re: hiding global variables
    ... because you may be placing the security fence at the ... we hold sensitive data so we encrypt it. ... I presume then you are operating a scheme whereby the user enters a password which is used to decrypt a public-key which is then used to decrypt the database?That way, the program itself doesn't contain enough information to decrypt the data, until the password is entered. ... generate an individual key-file by encrypting the public key from with their password. ...
    (comp.lang.tcl)