APPLICATION MANAGEMENT

Managing encrypted information
As you consider what type of encryption you need in your application, keep the following in mind:

Reading encrypted information

Users can read encrypted information if they have the correct secret encryption key in their IBMR LotusR NotesR User ID or, in the case of encrypted mail messages, the private key in their Notes User ID. Users without the correct encryption key can read unencrypted parts of a document, but encrypted fields appear blank. The user will see a dialog box with the message, "Portions of this document have been encrypted and are not intended for you."

When multiple keys are associated with a form or document, users need only one of the specified keys to read encrypted information.

Editing and saving encrypted information

Users who don't have the correct encryption key in their Notes User ID can't edit encrypted documents. They can create new documents but must save them unencrypted by removing the encryption key from the Document Properties box.

When multiple secret keys are associated with a form or document, users need all of the specified keys to edit and save encrypted information with the original keys. If they don't have all the necessary keys, they can still encrypt documents with the keys they have by changing the encryption key list in the Document Properties box.

Removing or changing encryption keys for a document

Authors can remove encryption or change the associated keys from their own documents (if they are allowed to edit their documents and they have all associated encryption keys). Editors can remove encryption from and change the keys associated with any document.

Data security for encrypted information

If a user copies a database, the data remains encrypted -- even if the database is copied at the operating system level. The encrypted data is also safe from access by API programs.

When an encrypted database is full-text indexed and the option "Index encrypted fields" is enabled, the encrypted fields are only indexed if there is an encryption key in the ID file capable of decrypting the field before indexing. One situation where you may want to index encrypted fields is if you create a full-text index for a database on your own workstation. You probably would not choose this option on a full-text indexed database on a server.

Note Data in the full-text index is stored unencrypted.

Field encryption and views

As you plan your design, keep in mind that encrypted fields do not display in views. This is a deliberate restriction to maintain security and to avoid the performance degradation that would result from having to decrypt data as the view sorts.

See Also