Uploaded image for project: 'Shiro'
  1. Shiro
  2. SHIRO-381

Function to repeatedly generate same encryption key

    XMLWordPrintableJSON

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Cryptography & Hashing
    • Labels:
      None

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              drmike01 Michael Swiernik
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: