Project

General

Profile

Actions

Task #2633

closed

Remove unimplemented encrypt/decryptInTpm

Added by Anonymous over 9 years ago. Updated almost 8 years ago.

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

0%

Estimated time:

Description

SecTpm::encryptInTpm and decryptInTpm throw an unimplemented exception. It was decided that encryption does not belong in the NDN library since it is not part of NDN. Therefore, should remove these methods.


Related issues 1 (0 open1 closed)

Blocks NDN-CCL - Task #2367: In security library, remove encrypt/decrypt and support for symmetric keysAbandoned01/09/2015

Actions
Actions #1

Updated by Anonymous over 9 years ago

  • Blocks Task #2367: In security library, remove encrypt/decrypt and support for symmetric keys added
Actions #2

Updated by Anonymous over 9 years ago

Hi Yingdi. Now that your are implementing the Group-Based Encryption Protocol, do you plan to keep the encrypt/decrypt methods in the ndn-cxx SecTpm? (maybe for non-group encryption?)

Actions #3

Updated by Junxiao Shi over 9 years ago

  • Start date deleted (03/10/2015)

do you plan to keep the encrypt/decrypt methods in SecTpm?

TPM is not the right place for symmetric encryption. ndn::security::transform could provide this feature.

Asymmetric encryption should be provided by TPM, because it involves private key usage similar to signing.

Actions #4

Updated by Yingdi Yu over 9 years ago

@Jeff, I think we will keep the decryption interface because it requires private key. For symmetric key, it is usually used as a nonce key, so unless we have some use case that require long lifetime nonce key, the encrypt/decrypt interface for symmetric key will not be supported in TPM. And as junxiao mentioned that, we will provide transform classes for symmetric encryption.

Actions #5

Updated by Anonymous over 9 years ago

OK, you'll keep the decryption interface for private keys. But do you plan to keep the interface for symmetric encryption? For example the ndn-cxx security library defines AesKeyParams, etc.:
https://github.com/named-data/ndn-cxx/blob/fe4a91880533579a5bb95c8039736258a1a5c338/src/security/key-params.hpp#L165

Is it OK if this duplicates AesEncryptKey from NDN group encrypt?
https://github.com/named-data/ndn-group-encrypt/blob/c61cf198cbf49f4ddd8fc664d4984146335ce866/src/algo/aes.hpp#L49

Actions #6

Updated by Anonymous over 9 years ago

... I see now that Aes.generateKey does use AesKeyParams from ndn-cxx:
https://github.com/named-data/ndn-group-encrypt/blob/c61cf198cbf49f4ddd8fc664d4984146335ce866/src/algo/aes.hpp#L37

So, the GEP library does re-use some of the symmetric key definitions from ndn-cxx.

Actions #7

Updated by Junxiao Shi about 9 years ago

  • Subject changed from security: Remove unimplemented encrypt/decryptInTpm to Remove unimplemented encrypt/decryptInTpm
  • Category set to Security
Actions #8

Updated by Alex Afanasyev almost 8 years ago

  • Status changed from New to Abandoned

This task is no longer applicable to the new security primitives.

Actions

Also available in: Atom PDF