6

I'm using jbcrypt to hash passwords in a project. Performance is about 500 ms when validating passwords on the hardware I am using (log_rounds set to 12). However, after a while with regular use the performance time suddenly drops to a whopping 15 seconds. The drop is very sudden with no buildup and stays constant until the process is restarted.

Profiling shows that the extra time is used in the key(..) method.

Source: http://jbcrypt.googlecode.com/svn/tags/jbcrypt-0.3m/src/main/java/org/mindrot/jbcrypt/BCrypt.java

This method only calculates the hash using basic functions like xor, and, shift etc. There is no object assignments, usage of external resources, random number generation etc.

Performance does not drop for other functionality in the same process. Memory allocation is stable and low. Full GC is not involved.

Has anyone seen this before or any clue to why this happens? I could understand a variable performance that to some degree was dependent on other circumstances, but this is a very sudden and stable drop from about 500ms. to about 15000 ms.

sstendal
  • 3,148
  • 17
  • 22
  • What function are you calling to validate the passwords? – LaJmOn Feb 12 '14 at 14:55
  • `key` itself is simply fixed-length loops over calls to `streamtoword` and `encipher`. Did your profiling identify the aggregate time spent in those methods? – Joe Feb 15 '14 at 10:15
  • Could you try tool like visualvm? It is light weight, may help to identify bottleneck. – Jayan Feb 15 '14 at 11:50
  • @joe Not exactly those two methods, but I agree that it is likely that the time is used there. – sstendal Feb 15 '14 at 21:54

2 Answers2

4

It's possible that SecureRandom is running out of entropy and causing this issue.

See How to solve performance problem with Java SecureRandom?

Community
  • 1
  • 1
LaJmOn
  • 1,824
  • 13
  • 14
  • 1
    That could have been the reason, but SecureRandom is only used by the library when it generates a new salt, and that part is not used when validating passwords. – sstendal Feb 08 '14 at 21:11
3

It turned out that this had something to do with classloading. The library was loaded in many different classloaders. The problem disappeared when we loaded the library in the system classloader.

sstendal
  • 3,148
  • 17
  • 22