All of the salts used in the add-on are randomly generated when they are first needed and stored in the database. This prevents the salts from being known ahead of time. Currently there are three different salts used in the add-on. First is the password salt. This salt is used along with the master password for deriving an encryption key. Second is the salt used as the initialization vector for the AES encryption. The third and final salt is used in the hash of the password-derived key that is stored in the database and used to verify that the correct master password is entered.
The first time the add-on is unlocked it prompts for a master password. The encryption key is then kept in memory and used to encrypt the public and private keys before they are written into the database. It is also used upon retrieval to decrypt the keys for use in authentication. When the browser is closed the add-on is unloaded from memory and the key is gone. After Firefox is relaunched the add-on will need to be unlocked again. The password will be verified to match the stored hash in the database.
The keys are stored in an SQLite database. Both the public and private keys are encrypted with AES using a randomly generated 256-bit key. This key is stored in the database encrypted with a key derived from the master password. This key is derived using 2048 iterations of PBKDFv2 using the master password and randomly generated salt.
The database should be safe and unusable without the master password to regenerate the encryption key. All of the keys are kept encrypted. The domains and the association between key pairs and the domains are visible in plaintext. This is to facilitate much faster access because otherwise to find the correct key pair for a domain every single domain would need to be decrypted and checked in order to find the correct one.
Currently the data from the server is unverifiable. The domain and MAC are used as a check but do not allow the add-on to verify the server that it came from. A traditional SSL connection to the webserver will negate this issue however. Also, when the server receives the response it IS able to verify that the original message and the response from the client weren't modified.
Right now there are a few major limitations with the TrustAuth system. These include the following:
There are a few solutions that I think mitigate several of the above limitations.