Rajesh,
I think you'll figure out what database/table design works best for all your use cases. There still is a way signatures bound to a single signature table work best for different things by establishing N:M relationships with additional tables that have at least the signatureid and another id to relate the signature to, perhaps also a third and fourth id.
As I said a part of the file name could point to the actual person to verify that you likely thought of protecting that info as it allows to collect signature files of the same person. Well, if a hacker collects all gif files I think it's easy to group the signatures and then also find matches with names from the graphics themselves.So that kind of protection isn't necessary.
And encryption as the tool to protect the names also isn't what I'd do. The usual aim of an encryption is to decrypt what you know you need, but surely not to need to decrypt every file name before you find the one you need. So this would indicate you don't do that but create a or a few hashes from record data that you can reproduce to know the file name. But what contradicts that as a way to prevent manipulation is whatever name one GIF has, a replacement GIF just needs to have the same name. So you're not safe against that replacement manipulation, you're only safe the GIF name doesn't reveal a userid in itself.
To still stick to the idea that part of the file name enables verification of the person, using a personid hash also would mark all signatures with the same hash instead of the same id number. So if you make that a concern mor important than its use is, then you better only give the filles a name of an id that doesn't directly relate it to anything else but a signature record and additional data determins the relationship of that signature to person, purpose, appointment, date, contract or other details. That obviously makes that data a weak point for manipulations, which can always be protected with hashes and backups. Backups stored with higher security would be able to reveal manipulation even if a hacker knows what hash to compute that a record looks valid. A signature should never be changed after it has been recorded.
Someone who simply copies all GIFs would likely find signatures that can be matched to user names by some kind of OCR or manually figuring out names roughly by length/letter count. While many signatures don't allow letter counting a signature usually does have a similarity with the actual name it's for. The use case to harvest the GIFs would be to fake signatures on contracts. Employees could fake contracts to get provisions from them, though sooner or later that could shoot back at them but signatures could be used anywhere else, too.
That speaks for encrypting the gif file contents themselves, mainly. The prevents misuse of the graphics themselves, which only will be displayed or printed decrypted when necessary by users that have the permissions for these use cases. And Windows vault allows to store credentials or certificates for just one EXE, so there you gain the safety of this secret.
Chriss
