Results 1 to 9 of 9

Thread: What do you guys think of this...?

  1. #1
    Antionline Herpetologist
    Join Date
    Aug 2001
    Posts
    1,165

    What do you guys think of this...?

    I've recently been asked to write a crypto program by a client. It's being done in VB/Access/Visual C++. So far, I've thought of something like this...

    1. Use a strong symmetric cipher system like twofish or similar to encrypt the Access mdb.
    2. The key is stored in multiple, persistent variables that are checked so that they aren't contiguous in memory.
    3. Password protect the program and store the password as a md5 hash in two distinct places in the registry.
    4. If the hashes don't match, wipe the program, but not the data.
    5. If the password is entered wrongly more than x times, wipe the program, not the data
    6. Store a md5 checksum of the file somewhere, maybe in the registry.
    7. If the md5 checksum changes, wipe the program, not the data.
    8. Since the key is stored in the program, if the right encryption scheme is used, the encrypted mdb file is useless.
    9. Also, if the user accidentally deletes the program, all he has to do is reinstall the program and the mdb is decrypted.

    This might seem like overkill, but the user needs this kind of security. Any thoughts on how to improve this....?
    Cheers,
    cgkanchi
    Buy the Snakes of India book, support research and education (sorry the website has been discontinued)
    My blog: http://biology000.blogspot.com

  2. #2
    rebmeM roineS enilnOitnA steve.milner's Avatar
    Join Date
    Jul 2003
    Posts
    1,021
    Dunno what you are trying to protect, but I would add at least one element of the key in a removal device - USB Keyfob or similar.

    The problem I can see with you system, although minor, is if the system is cloned (using Ghost or similar) to readonly media then I can brute force the password to the program, without the program being deleted, to my hearts content.

    Having part of the key in a removable drive requires the ownership of the drive, as well as a clone of the system.

    Steve
    IT, e-commerce, Retail, Programme & Project Management, EPoS, Supply Chain and Logistic Services. Yorkshire. http://www.bigi.uk.com

  3. #3
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    Storing the key in the software itself is a bad idea. Even though you have split it in memory, reverse engineering the app would reveal how and where the key is stored. so you dont really need a password at all. Perhaps creating a hash of the users password and using that as key to encrypt the .mdb, that way the data is encrypted on the secret and not the access to the app. (Or is that not what you want???)


    -Maestr0
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  4. #4
    Senior Member
    Join Date
    Nov 2003
    Posts
    107
    For your number 9, i would get rid of it altogether. If your client is concerned about security, don't leave a gaping hole like that. I mean, depending on what your installer does and if the attacker can get ahold of it, he could bypass all your hard work. Also inline with what others have said, use removable media for storing at least part of the key on. If the user accidentally deletes the program, have them get you to build back what's needed for security's sake.
    Is there a sum of an inifinite geometric series? Well, that all depends on what you consider a negligible amount.

  5. #5
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    Try something like SCRAMDISK?

    Data re-encrypted with four passwords..........not immediately obvious either?

    Just a thought?

  6. #6
    why not ad a unique id, produced randomly by the installer which is written on to the usb thumb and have this id used to help decrypt the document
    Signature image is too tall!

  7. #7
    Antionline Herpetologist
    Join Date
    Aug 2001
    Posts
    1,165
    I thought of this too, but my client does not want removable media. I did tell him that not having the key on removable media would reduce security, but he says he can live with that. Also, from Maestr0's post, encrypting the data with the hash isn't a great idea as the hash has to be stored persistently (to check if the correct password has been entered). However, encrypting the key itself with the plain text password or a hash of the hash is a good idea. Thanks for starting that thought process...

    why not ad a unique id, produced randomly by the installer which is written on to the usb thumb and have this id used to help decrypt the document
    I need the data to be recoverable by my client in case the program is wiped (eg, he forgets his password). A random ID in the installer would kill my chances of that...

    The program is going to be installed on my client's laptop and the only way anyone (read law enforcement) would get hold of it would be to confiscate the laptop. That's why the program wiping idea. If I had to crack a program, the first thing I would try is a dictionary attack. In my program, that leads to the program being wiped (not deleted, wiped).


    Cheers,
    cgkanchi
    Buy the Snakes of India book, support research and education (sorry the website has been discontinued)
    My blog: http://biology000.blogspot.com

  8. #8
    Senior Member
    Join Date
    Sep 2003
    Posts
    500
    So wait, the encrypted data is stored in the program and then the program is password protected with that password stored in two places in the registry? Is this correct?
    You shall no longer take things at second or third hand,
    nor look through the eyes of the dead...You shall listen to all
    sides and filter them for your self.
    -Walt Whitman-

  9. #9
    Antionline Herpetologist
    Join Date
    Aug 2001
    Posts
    1,165
    Not exactly.
    1. The encrypted data is stored in a file outside the program.
    2. The key to decrypt the data is stored inside the program.
    3. The password itself is never stored anywhere. Instead a hash to the password is stored. By the very definition of a hash, the password cannot be recovered from the hash. The only way to check if the password is correct is to hash the entered password and compare the hashes.

    ====================================================================

    Another idea. Why not make the plaintext password a (variable) part of the key so that the key is only useful as long as the entered password is right. Once the program wipes itself, the hashes are gone, therefore even if the installer is found and the program is reinstalled, without the right password, the data cannot be decrypted.

    Cheers,
    cgkanchi
    Buy the Snakes of India book, support research and education (sorry the website has been discontinued)
    My blog: http://biology000.blogspot.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •