NAC

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

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

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.

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

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/

I see a commit to GitHub. Is this issue resolved?

https://github.com/named-data/name-bases-access-control/commit/8992e7327c412f1c5d5939423d50c7aa6a9cb371

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