the database environment are not encrypted. For this reason, it
may be possible for an attacker to read some or all of an encrypted
database by reading the on-disk files that back these shared memory
regions. To prevent such attacks, applications may want to use
in-memory filesystem support (on systems that support it), or the
<ahref="../api_reference/C/envopen.html#envopen_DB_PRIVATE"class="olink">DB_PRIVATE</a> or <ahref="../api_reference/C/envopen.html#envopen_DB_SYSTEM_MEM"class="olink">DB_SYSTEM_MEM</a> flags to the <ahref="../api_reference/C/envopen.html"class="olink">DB_ENV->open()</a> method, to
place the shared memory regions in memory that is never written to
a disk. As some systems page system memory to a backing disk, it
is important to consider the specific operating system running on
the machine as well. Finally, when backing database environment
shared regions with the filesystem, Berkeley DB can be configured
to overwrite the shared regions before removing them by specifying
the <ahref="../api_reference/C/envset_flags.html#set_flags_DB_OVERWRITE"class="olink">DB_OVERWRITE</a> flag. This option is only effective in the
presence of fixed-block filesystems, journaling or logging
filesystems will require operating system support and probably
modification of the Berkeley DB sources.
</p>
<p>
While all user data is encrypted, parts of the databases and log
files in an encrypted environment are maintained in an unencrypted
state. Specifically, log record headers are not encrypted, only
the actual log records. Additionally, database internal page
header fields are not encrypted. These page header fields includes
information such as the page's <ahref="../api_reference/C/lsn.html"class="olink">DB_LSN</a> number and position in the
database's sort order.
</p>
<p>
Log records distributed by a replication master to replicated
clients are transmitted to the clients in unencrypted form. If
encryption is desired in a replicated application, the use of a
secure transport is strongly suggested.
</p>
<p>
We gratefully acknowledge:
</p>
<divclass="itemizedlist">
<ultype="disc">
<li>
Vincent Rijmen, Antoon Bosselaers and Paulo Barreto for writing
the Rijndael/AES code used in Berkeley DB.
</li>
<li>
Steve Reid and James H. Brown for writing the SHA1 checksum
code used in Berkeley DB.
</li>
<li>
Makoto Matsumoto and Takuji Nishimura for writing the Mersenne
Twister code used in Berkeley DB.
</li>
<li>
Adam Stubblefield for integrating the Rijndael/AES, SHA1
checksum and Mersenne Twister code into Berkeley DB.
</li>
</ul>
</div>
<p>
Berkeley DB 11g Release 2 supports encryption using Intel's
Performance Primitive (IPP) on Linux. This works only on Intel
processors. To use Berkeley DB with IPP encryption, you must have
IPP installed along with the cryptography extension. The IPP
performance is higher in most cases compared to the current AES
