Hi Chris,
Glad you like it. I developed it for my secure DHT peer to peer database. Each node is secure and it takes multiple keys to retrieve any one piece of data. Keyholder was developed to protect the node key. Since each node holds a lot of data it was very important to use special handling for the key. I had been reading about new side-channel attacks and that the vulnerability increases the more you read and use a key even if it is only held in memory. On these nodes we use the key all the time so KeyHolder was born.
I'll have a look when I get a chance. They sound like useful changes.
All the best,
Ron
On Sat, Sep 19, 2020, 7:58 PM Chris Muller asqueaker@gmail.com wrote:
Hi Ron, I just love this KeyHolder thingy! :) Such a clever idea to resist a side-channel attack. I'm curious how you came across the idea..
I did commit some improvements (see below), which I've tested, and plan to use in projects going forward.
As always, review and feedback is welcome from anyone and everyone.
Regards, Chris
Name: CryptographyCiphers-cmm.23 Author: cmm Time: 15 September 2020, 5:52:41.154778 pm UUID: 6ba3b5f5-47e3-48f7-a871-89a4cc4c0774 Ancestors: CryptographyCiphers-tpr.22
Improvements to KeyHolder:
- It can now hold an Integer or ByteArray key.
- Replaced use of KeyHolderData with a simple Array. KeyHolderData
removed.
- Destroys itself upon image save, to ensure not to save its contents in
the image.
- More secure, now uses Rijndael (AES) instead of TripleDES.
- More secure, now destroys the prior encrypted key instead of waiting for
GC.
- Now relies on a Mutex for process syncronization rather than trapping
Error and retrying.
- Guards against invalid key access after it was destroyed.
- Better printOn: reveals its status.
- About 7X faster.