Re: Which is more secure RC2 or RC4 ?
- From: Paul Rubin <http://phr.cx@xxxxxxxxxxxxxx>
- Date: 15 Jul 2006 05:16:10 -0700
"Homer Simpson" <wushu.israel@xxxxxxxxx> writes:
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
I'm not impressed with the web site for that product but I'll look at
it a little more closely later.
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.
Right, it's near useless. You also have to think about the swap area,
where a copy of the key could land. For that matter, raw credit cards
could land there too.n
Basically I am working on an web-based online service ...
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.
I don't understand why you want to touch these credit card numbers at
all. Why not use an external service and let them worry about this
stuff? Their card fees (based on volume) might actually be lower than
trying to do it yourself, they do the approvals in real time online,
etc.
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,
If your application can decrypt the information (in order to send it
to the card billing service) then an attacker who can take over the
application can also decrypt the info.
You've also got the problem of how to get the decrypted numbers to the
billing place--is THAT taken care of? Remember you're postulating an
attacker taking over your server, so the app that talks to the payment
processor may be compromised too, and it sees ALL the card numbers.
If you're really approving these orders manually (say a couple batches
per day), one goofy solution may be to use public key encryption on
the online server, so it can encrypt but not decrypt. Have the
decryption key on a separate computer (laptop). When you approve
orders, download the encrypted card numbers to a USB pen drive,
physically move the pen drive to the laptop for decryption, and then
upload from the laptop to the payment processor. Connect the laptop
to the net through a firewall that blocks EVERY incoming AND outgoing
address except the payment processor's. Before you start, totally
reformat the laptop's hard drive, then reinstall the OS from brand new
CD's, install the payment app, and don't ever install anything else or
use the laptop for anything except uploading payments. This doesn't
have to be expensive--some 50 dollar laptop from Ebay may be enough
for this minimal usage.
1. The key should never be kept in the same place as the information.
Right, and you haven't proposed any way to accomplish that. Having it
in a different part of the same computer doesn't really count.
2. It's better to use a more advanced cipher, meaning AES instead of
RC2 or DES etc.
I have a sinking feeling from even seeing questions like that, but
see if Aspencrypt supports AES in EAX mode, and use that if you can.
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).
If you're using AES normally you'd use a 128 bit key so MD4/5 is fine.
MD4/5 (especially MD4) have some weaknesses for secure hash
applications but for this purpose it shouldn't be a problem.
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:
The AES key is 128 binary bits (or 192 or 256). You don't have to
concern yourself with about using more than 128 bits for AES, since
the rest of the application's security is so lame anyway. You can
convert a password to suitable bits with MD5 or SHA or whatever.
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.
By "random key" you mean binary key. You should not use a "password"
by the way. Use something that has real randomness in it. See
http://www.diceware.com
for a hokey but effective way of generating passphrases. Use at least
a six or seven word phrase if you use diceware for this, preferably
ten words. You don't have to memorize them or anything obviously.
I have a javascript app that generates diceware phrases:
http://www.nightsong.com/crypto/dice.php
to save you the trouble of rolling physical dice. It gives you five
word phrases, so for ten words just use it twice.
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?
Don't worry about 256 bits, you'll have to do your hashing differently
and you should use a twenty word Diceware phrase, but it's overkill.
Just use 128 bits.
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').
If the key is in a disk file on a machine that an attacker can
corrupt, you are doomed, it doesn't matter how many bits you use.
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.
No, the binary key by itself would be enough to decrypt the data.
Basically I wish to understand where exactly is a password stored, so
Basically there are two ways to do it: the cheesy way is to type the
passphrase into the server when you start it, so the key stays in
memory and is never written to disk. You have to take measures to
make sure it never gets written to swap as well. The serious way is
to use a host security module (HSM), which is an expensive piece of
hardware (although I guess for this low volume stuff there are cheap
ways to do it) that encapsulates the keys and does the crypto
operations. HSM's are used in systems that handle large numbers of
cards (e.g. payment processing services) but would normally not be
used by small retailers who do just a few hundred transactions per day
or whatever. Anyway, it's a genuinely troublesome chicken and egg
problem for many kinds of systems.
when you enter it to decrypt information the machine has to compare
Comparison doesn't come into it. The passphrase simply gets converted
to a fixed width bit string by running it through a hash function.
This is not a login authentication application, you're trying to make
an actual encryption key.
.
- Follow-Ups:
- Re: Which is more secure RC2 or RC4 ?
- From: Mike Amling
- Re: Which is more secure RC2 or RC4 ?
- References:
- Which is more secure RC2 or RC4 ?
- From: Homer Simpson
- Re: Which is more secure RC2 or RC4 ?
- From: Tom St Denis
- Re: Which is more secure RC2 or RC4 ?
- From: rossum
- Re: Which is more secure RC2 or RC4 ?
- From: Homer Simpson
- Re: Which is more secure RC2 or RC4 ?
- From: Joseph Ashwood
- Re: Which is more secure RC2 or RC4 ?
- From: Homer Simpson
- Which is more secure RC2 or RC4 ?
- Prev by Date: Re: Which is more secure RC2 or RC4 ?
- Next by Date: Re: Which is more secure RC2 or RC4 ?
- Previous by thread: Re: Which is more secure RC2 or RC4 ?
- Next by thread: Re: Which is more secure RC2 or RC4 ?
- Index(es):
Relevant Pages
|
Loading
