David That approach would work to a point - but once you are inside the UniVerse shell then the system is "open". This would apply to any O/S authentication method including UniObjects etc... If this is all that is needed - preventing *external* access then this is a solution. If it is deemed necessary to provide internal protection within the UniVrese environment then more is needed.
Gosh - we haven't even *considered* uv-net...... Regards JayJay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of djordan Sent: 24 January 2004 01:52 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
