NAC-ABE: Duplicated decryption for reused keys

[matianxing1992]

I have been using NAC-ABE to secure messages in a service invocation framework using its cache-producer. However, I found that even when using the same KEY repeatedly, the decryption time does not decrease. Upon inspecting the code at line 249 in https://github.com/UCLA-IRL/NAC-ABE/blob/master/src/algo/abe-support.cpp

, I noticed that a caching mechanism might be missing. This absence leads to the repeated decryption of the same encrypted symmetric key, each time consuming an additional 15-20ms (while AES decryption takes less than 1ms). I believe that implementing a caching mechanism here is necessary, as it would improve the performance of NAC-ABE, especially when using the cache-producer.

Yours sincerely,
Tianxing Ma

[matianxing1992]

@tianyuan129 Got it, moved here.

[tianyuan129]

Yeah sounds good. Do you have any further implementation plan to provide optimization?

[matianxing1992]

I want to cache the decrypted keys in a map and use the hash value of the encrypted keys as the key of this map. Do you have any other suggestion? For the time being, there's no limit to the size or time of the cache.

[tianyuan129]

Is there a limitation that prevent using names to index keys? -- the ideal way to manage NDN keys

[matianxing1992]

ABESupport::decrypt(oabe::OpenABECryptoContext& context, const PublicParams &pubParams,
const PrivateKey &prvKey, CipherText cipherText);
Names are not available in this function.

[tianyuan129]

I see, seems ContentKey class is entirely nameless, using hash to index should be fine.

[matianxing1992]

The collision of hash may result in unexpected failure, how about using encypted content key (which is a string) as the key?

[tianyuan129]

I don't think there is a fundamental difference..it's up to you.

[matianxing1992]

@tianyuan129 When I test the performance of NAC-ABE, I found setting up a OpenABE context takes around 5ms, while it's not necessary if we use cached key. I will create a new patch to solve this problem, thanks!

Tianxing