Right now I can think of only two requirements for plugin-specific information:

user <--> key associations

(detached) signature storage

Common "parasite" storage

Session attributes are easily accessible related on a client sessions base in Trac's Request object (req.session), without the need for a direct db connection.
So entries in Trac db table session_attribute seem like a perfect match for the first requirement - no need for an own db table here.
I've chosen the following dedicated names for related association types:

'sign_key'

'crypt_key'

'auth_key' (future)

Their meaning should be easily guessable from these names.

Dedicated "private" storage

For storing signature data we could resort to inline signed data, but I felt that this choice would restrict possible use cases too much.
So I chose detached signatures as the default. Resources stay unaltered by signing, and you will be able to sign text content as well as arbitrary binary/file data.