NFD » ndn-cxx

My benchmark results:

This is a known issue and I would like to reject this.

For security to be secure, private key should never be exposed to the application, not mentioning be cached in memory. This basically defeats the purpose of security and key protection in the first place (there are well-known "cold boot" attacks, where keys are being extracted from RAM). And as long the key is secured, there is obviously large overhead and we would see extremely slow performance, such the one with OSX keychain.

Separate issue #1204 should address signing performance problem, without sacrificing much of security benefits by clearly separating keys that are used by applications and user keys that can be used to sign application keys. The former keys can be "less secure" (as they are cheap), kept, and used directly from RAM.

I agree with the fix proposed in #1204. This issue may block low-latency / high-throughput applications from using signing in the current security library. Can its priority be increased and example code be provided for how applications should generate derived keys?

Jeff, I am afraid that this is NOT a priority question.
We do not have a solution at this time, no matter how high the priority one wants to set it.

One proposed solution to this Bug is Task #1204, although it has design challenges in itself.

At 20150803 conference call, Alex classifies this as a "corner case".

However, I disagree with this classification unless the default TPM for OS X is changed to something other than osx-keychain.