I posted this in Arev, but remembered that I am going to convert this project into OI, so I would need this also…..

Does anyone know of any data file Encryption program or method that can be implemented to data encrypt OI data file? iso auditors are asking me to do this…..

Thanks in advance

We've done this using simple MFSs - it is just a case of writing the MFS at an encryption level your auditors are happy with. (One of our systems recently passed testing at a governmental level so it is possible :)). OR if you installed the Universal driver you could hide the files so noone could see them and encryption would become moot.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Thank you for the response

"it is just a case of writing the MFS at an encryption level your auditors are happy with."

I'm not sure what this means. Is there different levels of encryption? I wasn't aware of this. I will have to ask the auditors what level they require.

I'm aware of mfs, but how do I encrypt the data. Do I need a key or program or something like this, or is there a routine in OI that I need to run to do this.

I'll run the universal driver passed the owner and see what he thinks.

Again thanks

Well a simple form of encryption would be to make Char(255) represent Char(0), Char(254) Char(1) etc but this can be cracked almost instantly. There are lots of different algorithms. OI does have one built in whic his quite good. See http://www.revelation.com/__85256DC1002A4A9E.nsf/0/4115ABDF8DE4560A85256EC80061AB69?OpenDocument.

But the Universal Driver seems the easiest way forward. Can't try to decrypt what you can't find.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Just thinking … I was never encrypting records …

There is a lot of crypting algorithms, speed is not the biggest issue on < 64kB data.

When encryption (and I suppose decryption, too) are in thoughts.

One must ask which attacks you are scared of.

For most of people structure of *.LK + *.OV files may seem encrypted at all.

Encrypting records in *.LK + *.OV files using MFS (en+de cryption) prevents even people knowing *.LK, *.OV file structure. But everyone who opens the table from the AREV session (with instaled MFS according REVMEDIA) does not see an encryption at all (unless MFS requires a password during initialisation).

Of course MFS is the easiest solution in the sense nothing should be recoded.

What can improve the security is not to mention the MFS in the REVMEDIA, but mount it during the application startup. It does not prevent the "users" with TCL access to see the table contents, but it prevents the others.

Even this problem can be solved: You will have users which can switch their TCL access rights. During swithing you can add/remove the MFS.

… password requiring MFS does almost the same, during switching you just "forgot/remember" the password.

There should be mentioned a problem with MFS … you must index encrypted records.

You can also crypt the index, I don't see an additional problem here.

With UD, if the files are not seen except from AREV/OI, attacks from outside are blocked at all. But what about users with TCL rights?

…must index decrypted records (sorry language problems :) )

AREV/OI USers is an application security issue which is not what normally worries auditors. It is assumed that if they are within the application the application will judge what access they have and be tested accordingly. It is casual users browsing using Windows Explorer or using a Windows Search for *.LK;*.OV including text "Managing Director" and "Salary"… ;)

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

sorry again

time is of course very important in MFS programming, so codding must be very carefull, and a call to a routine in a low level language will be a big advantage.

BTW: If I understand it well, codding in low level language is behind the scope of us … AREV users.

No you can buy an assembler or a C interface for AREV programming. The C interface used to need an Aztec compiler so the assembler one might be better… see http://www.sprezzatura.com/revmedia/v4i4a5.htm

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

So in that case en/decryption:

CONVERT "rx" TO "xr" IN @RECORD is sufficient:)

and no low level language is required :)

I understand a bit more about it now. Thanks everyone. Andrew, could you send me a price on the assembler version that you have, at e-mail [email protected].

Also, I wanted to bring up the verb V66 as an option. Is this doable?

frank

Thanks again

Thanks for the link, I was afraid its a proprietary info ;)

- if it is on our site and it is about RevSoft it isn't proprietary as we're very careful…

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

View this thread on the forum...