Keep transformed master key in memory

2008-10-10
2012-11-20


  • 2008-10-10

    Are there any security objections against keeping the transformed master key in memory?
    The only thing affected by this is that the key for the AES transformations stays constant.
    Though I don't see how this could lower the security.

    I implemented this in KeePassX. As the time needed to save the database
    is dramatically reduced, I could add an option to automatically save the database
    after every change.

     
    • Dominik Reichl
      Dominik Reichl
      2008-10-10

      The idea behind the protection against dictionary and guessing attacks [1] is the following: we have a key provided by the user and transform it to form a different key, which is then used by KeePass in the encryption process. This transformation takes time (encrypting it repeatedly for a given time span) and an attacker has to do this transformation for each key and each database he tries.

      If the encryption key for the master key AES transformations is constant, you can precompute a plain text <-> result key table based on a dictionary. A company (providing password recovery) could for example compute such a table and then apply it to *all* databases instead of only a specific one (as the table would not be dependent on a key/seed anymore). This renders the whole key transformation process almost completely useless.

      For sure there are other cryptographic layers. Even if you remove the protection against dictionary attacks KeePass would still be pretty secure (like any other encryption product without this protection). Anyway, I want to provide KeePass users the strongest security possible, and will therefore not accept this change.

      Please let me know whether you want to keep your modification in KeePassX. If so, I will write a notice in the security documentation that KeePassX doesn't have this feature (anymore).

      Best regards
      Dominik

      [1] http://keepass.info/help/base/security.html

       
    • Dominik Reichl
      Dominik Reichl
      2008-10-10

      If your only goal is to speed up the file saving process, you could choose a random transformation key/seed and pre-compute a transformed key in the background (thread), such that you have one transformed key ready when the user wants to save.

      Best regards
      Dominik

       


    • 2008-10-10

      The transformation key is still random. The only thing that changes is, that it stays constant per database.
      So it is not possible to compute a rainbow table.

       


    • 2008-10-10

      To clarify this a bit more:
      Whenever the user creates a database/changes the key/changes the number of key transformation rounds/changes the encryption algorithm, the transformation key is randomly generated.
      On every other change the transformation key stays the same.

      I don't think that security is improved, when you change the transformation key on every database save. You just replace a random key by another random key.

       
    • Dominik Reichl
      Dominik Reichl
      2008-10-11

      If you do it like this (which is different from what you suggested in your first post), I agree that pre-computing a table is not possible. Although I currently don't see a simple attack on your scheme either, using a new random transformation key each time can only be more secure.

      I don't see why the risk of opening KeePass up to advanced cryptographic attacks should be taken, just for a minor speed optimization, which can even be achieved in a different and secure way (background thread).

      Best regards
      Dominik

       
    • wellread1
      wellread1
      2008-10-11

      I wonder if placing the computing load (transformations) only at the points where it positively affects security might be a net security win.  If one reduces the transformation time delay for the save operations, users might be willing to use more/longer transformations at database creation, startup & unlocking thereby increasing resistance to dictionary attacks. 

       
      • go2null
        go2null
        2008-10-31

        As a lay user, the save time doesn't bother me - and I run off a slow USB stick.