Project

General

Profile

Bug #3812

Change logic in GroupManger.getGroupKey() to avoid regenerate group key pairs every time.

Added by Zhiyi Zhang over 3 years ago. Updated about 2 years ago.

Status:
Abandoned
Priority:
Normal
Assignee:
Start date:
10/16/2016
Due date:
10/17/2016
% Done:

100%

Estimated time:
3.00 h

Description

Each time GroupManager.getGroupKey is called, the group's E-key and all of its current members' D-keys are regenerated.

#1

Updated by Zhiyi Zhang over 3 years ago

  • Status changed from New to Code review
  • % Done changed from 0 to 80
#2

Updated by Zhiyi Zhang over 3 years ago

Seems there is no one reviewing the code. Wonder who can do this?

#3

Updated by Zhiyi Zhang over 3 years ago

  • Status changed from Code review to Closed
  • % Done changed from 80 to 100
#4

Updated by Jeff Thompson over 3 years ago

This change stores the unencrypted private key in the Sqlite file. Have you thought about the security risks of this? Did you consider if it would it be better to keep the private key in memory between calls to getGroupKey?

https://github.com/named-data/ndn-group-encrypt/blob/master/src/group-manager-db.cpp#L342

#5

Updated by Zhiyi Zhang over 3 years ago

Jeff Thompson wrote:

This change stores the unencrypted private key in the Sqlite file. Have you thought about the security risks of this? Did you consider if it would it be better to keep the private key in memory between calls to getGroupKey?

https://github.com/named-data/ndn-group-encrypt/blob/master/src/group-manager-db.cpp#L342

Yes, there could be a security problem, I will try to figure it out.

#6

Updated by Jeff Thompson over 3 years ago

  • Status changed from Closed to Feedback

Status changed to Feedback while reviewing the security concern for storing raw private keys.

#7

Updated by Zhehao Wang over 3 years ago

Zhiyi Zhang wrote:

Yes, there could be a security problem, I will try to figure it out.

@Zhiyi I wonder if there are any updates to this?

(This update in CCL would be helpful for the current NDNFit application.)

#8

Updated by Zhiyi Zhang over 3 years ago

Zhehao Wang wrote:

Zhiyi Zhang wrote:

Yes, there could be a security problem, I will try to figure it out.

@Zhiyi I wonder if there are any updates to this?

(This update in CCL would be helpful for the current NDNFit application.)

https://gerrit.named-data.net/#/c/3784/

#10

Updated by Jeff Thompson about 3 years ago

In group-manager-db.hpp, cleanEKeys is private but nothing calls it. Maybe it should be public so that the application cal call it periodically?
https://github.com/named-data/name-bases-access-control/blob/67f90aa6610bf936d87712c6992c4727d7f5d9b8/src/group-manager-db.hpp#L195

#11

Updated by Alex Afanasyev about 2 years ago

  • Status changed from Feedback to Abandoned

Also available in: Atom PDF