Project

General

Profile

Actions

Feature #2488

open

Asynchronous API for data signing

Added by Alex Afanasyev over 9 years ago. Updated almost 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Security
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Given signing can be a time-sensitive operation, it can be desirable to use asynchronous API for it.


Related issues 1 (0 open1 closed)

Related to ndn-cxx - Bug #1589: KeyChain::sign is slow with tpm=osx-keychainRejected05/10/2014

Actions
Actions #1

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.
Actions #2

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?

Actions #3

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).

Actions #4

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.

Actions #5

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.

Actions #6

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.

Actions #7

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.

Actions #8

Updated by Yingdi Yu over 9 years ago

If we are using the real tpm, signing is usually done by a separate process.

Actions #9

Updated by Junxiao Shi over 9 years ago

  • Related to Bug #1589: KeyChain::sign is slow with tpm=osx-keychain added
Actions #10

Updated by Junxiao Shi over 9 years ago

At 20150803 conference call, Alex reveals the motivation of this Feature is #1589.

Actions #11

Updated by Alex Afanasyev almost 9 years ago

  • Target version changed from v0.4 to v0.5
Actions #12

Updated by Davide Pesavento almost 7 years ago

  • Target version deleted (v0.5)
Actions

Also available in: Atom PDF