Yes, using a cryptographic file system to provide encryption services is my preferred strategy. But, we're still negotiating requirements so I'm trying to keep my high-level design options open.
As JayJay pointed out, there are some "issues" with this solution. Essentially, after OS security is breached your data is exposed. That may, or may not be good enough... depending on your viewpoint. Some people trust their capability to lock down the OS. And other people are pessimistic about their capability to lock down the OS to their satisfaction and they want another barrier between the data and intruder. Tom Firl Columbia Ultimate > -----Original Message----- > From: djordan [mailto:[EMAIL PROTECTED] > Sent: Friday, January 23, 2004 5:52 PM > To: [EMAIL PROTECTED] > Subject: RE: Database Level Encryption > > > Hi Tom > > I haven't follow the total chain of this, but do you want the data > encrypted for external users or for other universe users. > Could you not > do something like with MS Windows where you set the directory to > encryption, the user does not have to do anything as the OS does the > encryption. You would not have to change anything in the > application or > in Universe, as Windows will encrypt/decrypt the Universe IO to the OS > files. The Datafiles will be encypted. > > Just an idea > > Regards > > David Jordan > Managign Consultant > [EMAIL PROTECTED] > > Dacono Holdings Pty Ltd > Business & Technology Consulting > PO Box 909 > Lane Cove > NSW 2066 > Australia > Ph 61 2 9418 8329 > Fax 61 2 9427 2371 > www.dacono.com.au > > > > -----Original Message----- > From: Tom Firl [mailto:[EMAIL PROTECTED] > Sent: Friday, 23 January 2004 2:57 AM > To: [EMAIL PROTECTED] > Subject: RE: Database Level Encryption > > > Thanks Wol, I'll let you know what we end up doing for the encryption > part of the project... The requirements for encryption strength still > need to be worked out, but I don't expect we'll be dealing with > ultra-strong encryption. > > The bigger concern at this point is finding a way to slide > encrypt/decrypt operations between the app and the data > store. Neither > Universe nor the application are well suited for this type of design > change. jBASE is much better at dealing with I/O layer > extensions, but > that is not an option for this project. Anyway, it's looking > like we'll > have to create an extensible I/O library for the application, then add > an encrypt/decrypt layer... it's a pretty good design principle, but > making the change on a 20 year-old, monolithic application is > a big job. > > Tom Firl > Columbia Ultimate > > > -----Original Message----- > > From: Anthony Youngman > [mailto:[EMAIL PROTECTED] > > Sent: Thursday, January 22, 2004 1:19 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Database Level Encryption > > > > > > I've written an enigma encryption function in the past. I'm > not saying > > > it was any good ... and in these circumstances it might well not be. > > > > But it would be very easy, using such a function, to say > "only encrypt > > > certain characters, leave others unchanged", so you could > scramble all > > > characters and numbers but leave uv marks alone. This has other > > repercussions, like giving away field lengths - you may not > want to do > > > that. > > > > And, DO discuss what you plan to do here. There are hundreds > > of examples > > of people thinking up clever schemes, making elementary > mistakes, and > > the resulting "security" is non-existent. Think Adobe/Sklyarov. Some > > clever clogs at Adobe took what was actually a good > encryption system, > > "enhanced" it, and the end result was a Caesar cipher. In > > case you don't > > know, that's "shift every character x places to the right in the > > alphabet" cipher. I cracked loads of those as a schoolkid. > > > > Security is ONLY effective if you know you can tell an attacker > > everything except the key, and you know that that > information is not > > going to help him one little bit. > > > > The other thing, of course, is all this effort and everything > > worth it? > > We sell a product that has time value. It's encryption-protected, of > > course, so all our customers get the same CD but can only access the > > bits they've paid for. But rather than go for ultimate > security, we've > > gone for something that (a) isn't easy to crack, but (b) our biggest > > danger is users sharing keys, so it leaves a highly visible > key-trail! > > So if our customers share keys and we visit them (which we do, > > frequently), we will probably notice which keys are being used! > > > > Cheers, > > Wol > > > > -----Original Message----- > > From: John Jenkins [mailto:[EMAIL PROTECTED] > > Sent: 21 January 2004 23:14 > > To: [EMAIL PROTECTED] > > Subject: RE: Database Level Encryption > > > > 3.3 Store the resultant encrypted data in your hashed fies in a > > "stuffed" format using a precursor byte: > > > > e.g. (hex representation of binary data for illustration only) > > > > uncoded : HELLO (etc) > > If x0C were the "stuffing byte" then this might become (after > > encryption) > > coded : x0DAB0C09FEFEDB44FF00BE (stored as binary of course > - not hex > > string) > > > > However this binary string contains a xFF (a no-go area) so > > the xFF gets > > re-encoded as x0C4FF4 (lo-hi) indicating that the character has been > > split > > into two character (binary) pairs with a "4" as a pad > binary digit and > > these > > must be ANDed with x0F and xF0 respectively and then the two > > bytes ORed > > to > > get the actual data byte. > > > > The binary string also contains a data byte x0C and this is our > > precursor or stuffing character - so: we "stuff" this to > x0C0C (note > > the second byte > > is > > not x4* so it cannot be a split data byte) and this means > > that this x0C > > is a > > *real* x0C and not a halved byte precursor instruction on the > > following > > data > > byte pair. > > > > Finally: The binary string also contains x00 - and this can > > cause issues > > (if > > calling C functions for example) so this is similarly re-encoded to > > x0C4004 > > - the same manipulation as the xFF gets us the appropriate result. > > > > > > > > > > ************************************************************** > > ********************* > > > > This transmission is intended for the named recipient only. > > It may contain private and confidential information. If this > > has come to you in error you must not act on anything > > disclosed in it, nor must you copy it, modify it, disseminate > > it in any way, or show it to anyone. Please e-mail the sender > > to inform us of the transmission error or telephone ECA > > International immediately and delete the e-mail from your > > information system. > > > > Telephone numbers for ECA International offices are: Sydney > > +61 (0)2 9911 7799, Hong Kong + 852 2121 2388, London +44 > > (0)20 7351 5000 and New York +1 212 582 2333. > > > > ************************************************************** > > ********************* > > > > > > -- > > ________________________________________________________ > > Unsubscribe: mailto:[EMAIL PROTECTED] > > or mailto:[EMAIL PROTECTED] > > Moderator : mailto:[EMAIL PROTECTED] > > Web-site : http://www.oliver.com/lists/u2 > > > > > > > > -- > ________________________________________________________ > Unsubscribe: mailto:[EMAIL PROTECTED] > or mailto:[EMAIL PROTECTED] > Moderator : mailto:[EMAIL PROTECTED] > Web-site : http://www.oliver.com/lists/u2 > > > _______________________________________________ > u2-users mailing list > [EMAIL PROTECTED] > http://www.oliver.com/mailman/listinfo/u2-users > _______________________________________________ u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users