Re: Which is more secure RC2 or RC4 ?

Homer Simpson wrote:
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
Had a look. Doesn't look good to me at all.


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...
We can, today, reasonably crack 64bit keys. Knowing that a 128bit key is on
a, say, 500GB HD reduces the keyspace to 35 bit. Less, if the keystring is longer.


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.
I would not do it like this. I'd keep the credit card numbers in memory
only and use ssl to communicate with the application keeping that
memory. Or, if windows offering some authenticated IPC, I'd use that.
That way, database hacking and media theft are covered (swap needs to be
taken care of).


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),
If by MSSQL you mean SQLServer by microsoft, they got a security concept
on their own, complete with infrastructure and guidelines for safe
use. Btw, they store the ENCRYPTED key in the registry and use a special
API (DPAPI) for it.
I strongly suggest you look up Microsofts default way of encrypting data
with SQL Server 2005:
http://msdn2.microsoft.com/en-us/library/ms189586.aspx
and go from there. SQLServer 2005 offers AES too.

If you want to convert your own working hours into security, I'd stop
bothering about encryption, use microsoft's stuff for that and spend
my time on securing the other aspects of your system, like DMZs,
physical security, LAN security, access control and all the other stuff.

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.
No, the point of the hash is to concentrate entropy. If, for instance,
you want a 128bit key, you throw a dice 50 times and get a 400 bit
ascii string. This you can concentrate into a 128 or 160 bit hash
usable for the encryption algorithm.
Or, in short, a hash turns a passphrase into a key which is random at the
bit level. If you can generate such keys on your own you don't need the hash.

Lots of Greetings!
Volker

--
For email replies, please substitute the obvious.
.

Relevant Pages

  • Re: SQL or Access DB
    ... As far as encryption goes though... ... with Sql Server you can use SQL DMO and encrypt your stored procedures ... installation - Security was absolutely critical and in most instances, ... > then we create a nice gui around this database and sell it to automotive ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Cryptography in SQL Server 2000
    ... A company is vulnerable when its security ... > database encryption solution with protected key-management software ... > tested by the SQL Server Test Lab. ...
    (microsoft.public.sqlserver.security)
  • 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: Secure Transactions over HTTPS????
    ... we were doing 80,000 credit card transactions a day. ... Where the weak part is usually, is hackers getting to the database. ... Internet firewall) so that the only access was via VPN to the private ... The VPN was not for the encryption, ...
    (Focus-Microsoft)
  • Re: Which one is the best encryption algorithm
    ... If the security of the database is a concern, ... if *both* the database and the server app is compromised ... write access to the credit card field, ... Asymmetric encryption. ...
    (borland.public.delphi.non-technical)