Feature #1564
closed
Should SecTpmFile cache the keys in memory?
0%
Description
Each time SecTpmFile needs a key, it goes to the file system, reads the key, decodes base64 and decodes DER. After reading a key for the first time, should it cache it in memory? Maybe use a SecTpmMemory internally as a cache?
Updated by Junxiao Shi over 10 years ago
- Tracker changed from Task to Feature
- Category set to Security
- Target version set to v0.2
It's unnecessary to make this change.
Operating systems can cache recently used files in memory.
No actual disk operation will occur if the private key file is recently used.
Updated by Anonymous over 10 years ago
Hi Junxiao,
You say it's unnecessary to make this change, but your Bug #1589 shows that the osx-keychain TPM can only sign 50 packets per second. But using a memory cache it is possible to get at least an order of magnitude improvement. Isn't that worth looking at?
Updated by Anonymous over 10 years ago
Hi again Junxiao. This bug report is about the file-based TPM, not the osx-keychain TPM. But the point stands. Your test shows that the file-based TPM can sign about 400 data packets per second. Using an in-memory private key (and OpenSSL instead of Crypto++) gets about 4000 packets per second.
Updated by Junxiao Shi over 10 years ago
- Status changed from New to Rejected
- Start date deleted (
04/30/2014)
20140612 conference call decides that key signing key SHOULD NOT be cached in memory.
SecFileTpm is a store for key signing keys.
It is not performance-critical because key signing keys is only used to sign data signing keys.
The store for data signing keys is performance-criticial, but it's not the purpose of SecFileTpm.