439
edits
NSS Shared DB: Difference between revisions
Jump to navigation
Jump to search
→Special coding for encrypted entries
| Line 195: | Line 195: | ||
===== Special coding for encrypted entries ===== | ===== Special coding for encrypted entries ===== | ||
Encrypted entries are stored in the database as pkcs5 encoded blobs. | |||
SEQUENCE { | |||
AlgorithmID algorithm, | |||
OctetString encryptedData | |||
}; | |||
The algorithm parameter must be a valid PKCS5 or PKCS12 PBE oid, and contain the appropriate salt value. NSS understands the following PBE oids: | |||
*SEC_OID_PKCS12_PBE_WITH_SHA1_AND_TRIPLE_DES_CBC | |||
The base key used in the PBE is the token password hashed with the token's global salt stored in the password entry. <In FIPS mode this resulting key is further transformed by setting it to value 'x' and using x to raise generator 'g' to the 'x' power modulo 'p'. The final result is the token key. g and p are stored with the base user's protection in the filesystem in the same directory as the certificate and key database. g and p should be considered 'secret' values.>* | |||
* Purpose: by choosing an appropriate g and p, we can control password attempt rates from multiple processes. By making g and p secret, we can remove our reliance on the security of the PBE - the security of the password is at least as strong as the security of g and p. | |||
This will be implemented by checking for the g/p file in the database directory. If no g/q file exists, key processing would continue as normal. If g/p does exist it will be used in the key formation. If a new key is being created, then g/p is create/used if in FIPS mode, and not create/used if not in FIPS mode. This way passwords continue to work even after mode switching. | |||
===== Special coding for MACed entries ===== | ===== Special coding for MACed entries ===== | ||