You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Michael Swiernik (JIRA)" <ji...@apache.org> on 2012/08/07 18:56:10 UTC

[jira] [Created] (SHIRO-381) Function to repeatedly generate same encryption key

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