Mega Code Archive
Key database
<![CDATA[
Database structure that allows you to securly store keys together with descriptions and other attributes.
Key Database
The main reason for using key databases is the use of large random
keys such as private keys. By storing these keys in a database along
with names and descriptions of each key you remove the need to
remember them. The user simply has to select the appropriate key by
its name and description. As information technology continues to
evolve and offer more ecurity measures, consumers will embrace key
database products.
There are many different ways to implement encrypted key databases.
Only one will be discussed because of it's dexterity. Although it
isn't very convenient for large databases, it is very dequate to
manage a few dozen keys.
The biggest concern is the key database's encryption key, it should
be lengthy but easy to remember. It is recommended to use phrases
for the simple fact that anyone can remember a 4 word phrase which
usualy contains 15-20 letters. The phrase should not be used as the
key intact; it should be reduced to offer as much entropy as can be
afforded. 128bits is a more han generous key size that provides
abundant security for this implementation of a key database.
The next issue is known plaintext; if an attacker knows most of the
names and description of the keys he can employ a known plaintext
attack. This sort of attack attempts to discern the key from bits
that are known to be in the encrypted data. These attacks require
massive amounts of known plaintext, but no chances can be taken. The
best way to stop known plaintext from compromising the keys in the
database is to encrypt all predictable information with a separate
key.
The key that encrypts the names and descriptions should either be a
key dedicated to this task, and contained in the database with the
other keys or a hash function of all keys in the database. Either
solution keeps the keys from being compromised by an attacker who
managed to decipher the names and descriptions.
The key database's structure should contain the least amount of
predictable bits as possible. Predictable data that cannot
compromise the keys should be at the beginning of the database and
should not be encrypted. With this in mind the size of the keys
should be stored in that manner. The next block of information
should be the sizes of the names and descriptions of each key. These
sizes do not reveal any security critical data.
Next in the database should be the keys. They should obviously be
encrypted. There should be no markers in between keys; they are
useless because their sizes are know, and you can easily calculate
each key's placement. If you choose to assign a key to encrypt the
names and descriptions it should be placed after all other keys and
encrypted in the same manner as all other keys.
After the keys should be the names and discriptions, and like the
keys the names and descriptions do not require markers.
This concludes this basic architecture for a properly implemented
key database. There are many more security concerns that need to be
accounted for on behalf of the software itself. Cleaning up of
memory after completion is necessary in all security-related
software. Security is a process, not a recipe.
(C)Copyright DrMungkee 2000
]]>