shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Swiernik (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SHIRO-381) Function to repeatedly generate same encryption key
Date Tue, 07 Aug 2012 16:56:10 GMT
Michael Swiernik created SHIRO-381:
--------------------------------------

             Summary: Function to repeatedly generate same encryption key
                 Key: SHIRO-381
                 URL: https://issues.apache.org/jira/browse/SHIRO-381
             Project: Shiro
          Issue Type: New Feature
          Components: Cryptography & Hashing
            Reporter: Michael Swiernik


I would like a way in Shiro to repeatedly generate my encryption keys so that I do not need
to store them anywhere. This is similar (I think) to how PBKDF2 works. For my use case, I'd
need this for both IV and non-IV encryption methods.

My use case is pretty straightforward:
I encrypt data in a database in the cloud using symmetric key. The database is separate from
my application server for a variety of reasons (actually on a different provider completely).
Since I need to obviously retain the encryption keys across system restarts and system scale
events, I am challenged with finding a way to store those keys in a way that the application
server can restart without manually entering them (and therefore its restart being dependent
on someone being available), but also not storing my encryption key in a database where somebody
could access it easily.

I've thought about using master keys to generate other keys, and/or storing fragments of keys
in different places (like half the key in my app code, and the other half in the database),
but each of these has issues. What I'd like to be able to do instead is to generate the same
encryption keys upon application restart and store those keys in memory only while the application
is running. 

Obviously whatever initialization code I used to do this would need to be accessible somewhere
too, but that could be handled in a few ways, and ultimately adds one more barrier to getting
the encryption key. One could argue that I could just handle my encryption key in that way
too, and there's some merit to that, but there's something scary about storing my encryption
key somewhere, plus I'd really need to find a 2nd database provider, complicating my deployment
substantially.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message