$Id: DESIGN.sgml.in 2305 2009-04-13 11:27:46Z rafi $
Copyright © 2008, 2009 Rafael Ostertag <rafi@guengel.ch>
Table of Contents
YAPET stores passwords encrypted on disk. Passwords are kept in records with additional information. A record is comprised by the following components:
The encryption and hash functions used by YAPET are provided by the crypto(3) library of ssl(3). YAPET does not provide them itself.
YAPET uses a master password provided by the user to generate a key in order to encrypt and decrypt the password records. The master password is not stored permanently. It has to be entered when a file is opened or the screen is locked in order to unlock it.
The encryption key is generated by calculating a SHA1 hash of the master password. MD5 is used to hash the SHA1 hash. Both hashes are concatenated. Finally, RIPEMD-160 is used to generate a hash of the SHA1 and MD5 hashes. The RIPEMD-160 hash is then appended to the SHA1 and MD5 hash, yielding a key of 448 bits. This key will be used for the Blowfish encryption algorithm in order to encrypt and decrypt password records.
A file created by YAPET has the following basic structure
The prefixes are stored in big-endian order, regardless of the endianess of the platform YAPET is running.
Each file created by YAPET starts with a unencrypted
recognition string which currently consists of the 8
bytes YAPET1.0 as depicted in
Figure 1, “Recognition String”.
Figure 1. Recognition String
+--------+--------+--------+--------+--------+--------+--------+--------+ | Y | A | P | E | T | 1 | . | 0 | | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | +--------+--------+--------+--------+--------+--------+--------+--------+
After the recognition string a 4 byte unsigned integer which is stored in big-endian order follows. This indicator is read to determine how many bytes to read in order to get the encrypted header (Figure 2, “Encrypted Header”).
Figure 2. Encrypted Header
+--------+--------+--------+--------+ | Length indicator in big-endian | | order (4 bytes) | +--------+--------+--------+--------+--...---+ | Encrypted header exactly as many bytes | | indicated by the prefix | +--------+--------+--------+--------+--...---+
The decrypted header (Figure 3, “Decrypted Header”) is 25 bytes in size. The first byte indicates the version of the file. The next 20 bytes are used as control string. After decryption, the control string is compared to the predefined clear text control string, in order to find out whether or not the key used to decrypt was the same used to encrypt.
Figure 3. Decrypted Header
+--------+ |Version | | 1 byte | +--------+--------+--------+--...---+ | Control String | | 20 bytes | +--------+--------+--------+--...---+ | Time when the Password | | was set (4 bytes) | +--------+--------+--------+
Each encrypted password record is prefixed by a 4 byte unsigned integer which is stored in big-endian order. That integer is used to indicate the length of the following encrypted data chunk.
Figure 4. Encrypted Password Record
+--------+--------+--------+--------+ | Length indicator in big-endian | | order (4 bytes) | +--------+--------+--------+--------+--...---+ | Encrypted password record of exactly as | | many bytes as indicated by the prefix | +--------+--------+--------+--------+--...---+ | Length indicator in big-endian | | order (4 bytes) | +--------+--------+--------+--------+--...---+ | Encrypted password record of exactly as | | many bytes as indicated by the prefix | +--------+--------+--------+--------+--...---+ [ . . . ]
Putting this together, an encrypted file created by YAPET may look like this
Figure 5. Encrypted File Example
+--------+--------+--------+--------+--------+--------+--------+--------+ | Y | A | P | E | T | 1 | . | 0 | | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | +--------+--------+--------+--------+--------+--------+--------+--------+ | Length indicator in big-endian | | order (4 bytes) | +--------+--------+--------+--------+--...---+ | Encrypted header exactly as many bytes | | indicated by the prefix | +--------+--------+--------+--------+--...---+ | Length indicator in big-endian | | order (4 bytes) | +--------+--------+--------+--------+--...---+ | Encrypted password record of exactly as | | many bytes as indicated by the prefix | +--------+--------+--------+--------+--...---+ | Length indicator in big-endian | | order (4 bytes) | +--------+--------+--------+--------+--...---+ | Encrypted password record of exactly as | | many bytes as indicated by the prefix | +--------+--------+--------+--------+--...---+ [ . . . ]
Memory used for storing sensitive information is cleared by
setting it to zero upon de-allocation. This is default behavior
of YAPET functions. However, YAPET cannot alter the way functions
provided by crypto(3) and curses(3X) de-allocates memory. An attempt
to make curses(3X) more secure is taken by
calling wclear(3X) before
calling delwin(3X), in the hope that
it clears the memory associated with the curses window.
YAPET
uses setrlimit(2)
to suppress the creation of core dumps. It also sets up signal
handlers
for SIGHUP, SIGINT, SIGQUIT, SIGTERM,
and SIGKILL for doing a proper cleanup and
clearing of allocated memory.
Apart from memory clearing, YAPET locks the screen after ten minutes of inactivity.
YAPET does not keep the password records decrypted in memory. It decrypts only the name of the password record in order to show it to the user. Password records are only decrypted for displaying and editing, when the user chooses to open a record.