By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,099 Members | 947 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,099 IT Pros & Developers. It's quick & easy.

Encrypting some fields

P: n/a
This idea is still in the process of formulation. I'm considering the
idea of storing encrypted data in memo fields. Since the data is for
internal use only I don't think the legal limits on encryption apply.
So memo fields are required because I want to use a couple of 500 or so
digit safe primes for the encryption. Note that public key encryption
has been around for quite a while so some organizations may have a
pretty large prime pair database :-). Each user would access the same
second prime number. Only some fields need to be encrypted such as
managers' comments. For unbound forms I'm looking at Decrypting when
filling the record and Encrypting when saving. I don't want the second
prime to be crackable so I'm thinking of using a function to piece the
prime together when required, perhaps calling it from a DLL. The
Decryption function could also require a password to be supplied that
is unique to each userid. For bound forms I'm considering:

textbox1 textfield unbound editable
textbox2 memofield bound uneditable

Form OnCurrent: Decrypt memofield into textfield
textbox1 AfterUpdate: Encrypt textfield into memofield

If this idea works out I might extend it to double encryption
capability where extra sensitive data will still be seen as encrypted
by normal users but viewable by management. I.e., management will have
another prime number available to the function used to decrypt those
fields. The problem with this whole idea is that if I make it easy for
the user by not having them type an encryption password I limit the
strength to that of the windows domain password encryption or to that
of Access Security. Also, without an encryption password or some other
variable thrown into the function, would a determined hacker armed with
an assembly code viewer eventually figure out how to get the second
prime number from the DLL code? Any suggestions, other than die and go
to he...aven?

James A. Fortune

Disclaimer: Why do I get these ideas so late at night?

Nov 13 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
ji********@compumarc.com wrote:
This idea is still in the process of formulation. I'm considering the
idea of storing encrypted data in memo fields. Since the data is for
internal use only I don't think the legal limits on encryption apply.
So memo fields are required because I want to use a couple of 500 or so
digit safe primes for the encryption. Note that public key encryption
has been around for quite a while so some organizations may have a
pretty large prime pair database :-). Each user would access the same
second prime number. Only some fields need to be encrypted such as
managers' comments. For unbound forms I'm looking at Decrypting when
filling the record and Encrypting when saving. I don't want the second
prime to be crackable so I'm thinking of using a function to piece the
prime together when required, perhaps calling it from a DLL. The
Decryption function could also require a password to be supplied that
is unique to each userid. For bound forms I'm considering:

textbox1 textfield unbound editable
textbox2 memofield bound uneditable

Form OnCurrent: Decrypt memofield into textfield
textbox1 AfterUpdate: Encrypt textfield into memofield

If this idea works out I might extend it to double encryption
capability where extra sensitive data will still be seen as encrypted
by normal users but viewable by management. I.e., management will have
another prime number available to the function used to decrypt those
fields. The problem with this whole idea is that if I make it easy for
the user by not having them type an encryption password I limit the
strength to that of the windows domain password encryption or to that
of Access Security. Also, without an encryption password or some other
variable thrown into the function, would a determined hacker armed with
an assembly code viewer eventually figure out how to get the second
prime number from the DLL code? Any suggestions, other than die and go
to he...aven?

James A. Fortune

Disclaimer: Why do I get these ideas so late at night?


Here's a starting point:

http://www.planet-source-code.com/vb...12023&lngWId=1
--
'---------------
'John Mishefske
'---------------
Nov 13 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.