Feature #2488
openAsynchronous API for data signing
0%
Description
Given signing can be a time-sensitive operation, it can be desirable to use asynchronous API for it.
Updated by Junxiao Shi over 9 years ago
So far NDN-JS has an async signing API, which is necessary to use crypto.subtle
.
In ndn-cxx,
- There isn't an equivalent of
crypto.subtle
that requires async API. - One context switch (or worse, thread creation) for every signing is too expensive.
- Merely deferring signing using
io.poll
brings little benefit, and would require using io_service in more places.
Updated by Davide Pesavento over 9 years ago
Junxiao Shi wrote:
- There isn't an equivalent of
crypto.subtle
that requires async API.
The requirement for an async API comes from above, not below. IOW we want to be able to sign stuff in an async manner from the main NFD thread without blocking unrelated forwarding operations. If ndn-cxx is not the proper place to implement this, we can do it in NFD.
- One context switch (or worse, thread creation) for every signing is too expensive.
This has to be measured, but as far as I understand the OSX TPM is extremely slow.
- Merely deferring signing using
io.poll
brings little benefit, and would require using io_service in more places.
Why is more usage of io_service
a problem?
Updated by Junxiao Shi over 9 years ago
This has to be measured, but as far as I understand the OSX TPM is extremely slow.
Yes, but only key-signing keys are stored in OSX TPM. When an app starts, a short-lived data-signing key is created and signed using key-signing key.
The data-signing key is stored in memory, and signing using data-signing key is fast.
(see #1204 for more details and challenges in this design)
The fundamental question is: what's the benefit to have async signing API?
Is actual signing done in same thread, or in a different thread?
If it's in same thread, what performance benefit can this bring?
If it's in a different thread, justify the complexity of managing a separate thread, and the overhead of context switching (compared to synchronous signing with in-memory data-signing key).
Updated by Yingdi Yu over 9 years ago
If the signing speed is the only reason, I think we should go with short-lived key solution, rather than making an async api. Even if multi-thread is available, application may have separate threads for signing, which does not necessarily require an async API.
Updated by Alex Afanasyev over 9 years ago
Signing speed is not the only reason. Signing operation (when considering real TPM) is by itself an asynchronous and on OSX it is already a separate thread (ok ok, it is really slow on OSX anyways).
What is proposed is to bring an option for the naturally asynchronous operation an asynchronous interface. In some cases (management in NFD) it would allow completely remove heavy processing inside forwarding path (even 1ms can be bad there).
The proposal is not to eliminate synchronous operation, rather provide an alternative option that can be used in some applications.
Updated by Junxiao Shi over 9 years ago
In NFD Management, we could move most processing into a separate thread (boundary at ManagementDispatcher), including everything from verification to signing, then use io.dispatch
to affect tables or faces. This is better than solely moving out signing, because verification and encryption are slow as well.
Please answer first two questions in note-3.
Updated by Davide Pesavento over 9 years ago
Junxiao Shi wrote:
In NFD Management, we could move most processing into a separate thread (boundary at ManagementDispatcher), including everything from verification to signing, then use
io.dispatch
to affect tables or faces. This is better than solely moving out signing, because verification and encryption are slow as well.
Yep, this could be done as well, I dunno how complicated it would be though as I'm not familiar with that part of NFD.
Updated by Yingdi Yu over 9 years ago
If we are using the real tpm, signing is usually done by a separate process.
Updated by Junxiao Shi over 9 years ago
- Related to Bug #1589: KeyChain::sign is slow with tpm=osx-keychain added
Updated by Junxiao Shi over 9 years ago
At 20150803 conference call, Alex reveals the motivation of this Feature is #1589.
Updated by Alex Afanasyev almost 9 years ago
- Target version changed from v0.4 to v0.5