Skip to content
This repository has been archived by the owner on May 25, 2021. It is now read-only.

Method for calculating a value for N depending on CPU speed #12

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 63 additions & 0 deletions src/main/java/com/lambdaworks/crypto/SCrypt.java
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,8 @@

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadMXBean;
import java.security.GeneralSecurityException;

import static java.lang.Integer.MAX_VALUE;
Expand All @@ -23,6 +25,12 @@
public class SCrypt {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you place this method inside the main class ?
Since it's use case is not part of "standard operations" why don't you extract it to another class ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're absolutely right, it belongs in ScryptUtil. I accidentally put it in Scrypt.java.
I'll push a fix. Thanks for pointing this out.

private static final boolean native_library_loaded;

// for timedIterations()
private static final byte[] BENCH_PASSWD = "secret".getBytes();
private static final byte[] BENCH_SALT = "1234".getBytes();
private static final int BENCH_DK_LEN = 32;
private static final int BENCH_INITIAL_N = 64;

static {
LibraryLoader loader = LibraryLoaders.loader();
native_library_loaded = loader.load("scrypt", true);
Expand Down Expand Up @@ -211,4 +219,59 @@ public static int integerify(byte[] B, int Bi, int r) {

return n;
}

/**
* Determines a CPU cost value (i.e. a value for the N parameter) that will cause password
* verification to take (roughly) a given time on the current CPU for the specified
* <code>r</code> and <code>p</code> values.<br/>
* N is rounded to the nearest power of two because only powers of two are valid
* choices for N. The actual time spent will be between about .7*<code>milliseconds</code>
* and 1.4*<code>milliseconds</code>.
*
* @param milliseconds the time scrypt should spend verifying a password
* @param r memory cost parameter
* @param p parallelization parameter
*
* @return a value for N such that <code>scrypt(N, r, p)</code> runs for roughly <code>milliseconds</code>
*
* @throws GeneralSecurityException when HMAC_SHA256 is not available.
*/
public static int timedIterations(int milliseconds, int r, int p) throws GeneralSecurityException {
ThreadMXBean threadBean = ManagementFactory.getThreadMXBean();
boolean cpuTimeSupported = threadBean.isCurrentThreadCpuTimeSupported();
boolean origEnabledFlag = false;
if (cpuTimeSupported) {
origEnabledFlag = threadBean.isThreadCpuTimeEnabled();
if (!origEnabledFlag)
threadBean.setThreadCpuTimeEnabled(true);
}

int N = BENCH_INITIAL_N;
long lastDelta = 0;
while (true) {
// prefer CPU time over real world time so the result is load independent
long startTime = cpuTimeSupported ? threadBean.getCurrentThreadUserTime() : System.nanoTime();
SCrypt.scrypt(BENCH_PASSWD, BENCH_SALT, N, r, p, BENCH_DK_LEN);
long endTime = cpuTimeSupported ? threadBean.getCurrentThreadUserTime() : System.nanoTime();
long delta = (endTime-startTime) / 1000000;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why you take a time in nano an divide it to a lower resolution ?
(femto if I'm correct)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm converting it to milliseconds so it matches the 'milliseconds' parameter.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure ?
First you are substracting two time in nano which mean that you end up with a time in nano (10^-9).
Then you divide this time by a million (10^6) (which is equivalent to multiplying by 10^-6) so you're ending with a more precise resolution (10^-15 ; 9+6=15): http://en.wikipedia.org/wiki/Femto-

seconds>millis>nanos>femto

To be honest I know I'm bad at it. This is why I always use TimeUnits.NANOSECONDS.toMillis(...) http://download.java.net/jdk7/archive/b123/docs/api/java/util/concurrent/TimeUnit.html#toMillis(long)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think of it in terms of seconds vs hours. Dividing gets you the lower (less precise) resolution, so to convert seconds to hours you divide by 3,600.
Converting nanoseconds to milliseconds (i.e. to a less precise resolution) works the same way, except you divide by 1,000,000.
That is exactly what TimeUnit.NANOSECONDS.toMillis() does:

public enum TimeUnit {
    NANOSECONDS {
        ...
        public long toMillis(long d)  { return d/(C2/C0); }
        ...
    },
    ...
    static final long C0 = 1L;
    static final long C1 = C0 * 1000L;
    static final long C2 = C1 * 1000L;
    ...
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, you win !


// start over if a speed increase is detected due to the code being JITted
if (delta < lastDelta) {
N = BENCH_INITIAL_N;
lastDelta = 0;
continue;
}

if (delta > milliseconds) {
if (cpuTimeSupported)
threadBean.setThreadCpuTimeEnabled(origEnabledFlag);
// round to the nearest power of two
if (delta-delta/4 > milliseconds)
N /= 2;
return N;
}
N *= 2;
lastDelta = delta;
}
}
}
24 changes: 24 additions & 0 deletions src/test/java/com/lambdaworks/crypto/test/SCryptUtilTest.java
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,12 @@
package com.lambdaworks.crypto.test;

import com.lambdaworks.codec.Base64;
import com.lambdaworks.crypto.SCrypt;
import com.lambdaworks.crypto.SCryptUtil;
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadMXBean;
import java.security.GeneralSecurityException;
import java.util.Random;
import org.junit.Assert;
import org.junit.Test;
import static org.junit.Assert.*;
Expand Down Expand Up @@ -56,4 +61,23 @@ public void format_0_rp_max() throws Exception {
assertEquals(r, params >> 8 & 0xff);
assertEquals(p, params >> 0 & 0xff);
}

@Test
public void testTimedIterations() throws GeneralSecurityException {
byte[] salt = "1234".getBytes();
int dkLen = 32;

ThreadMXBean threadBean = ManagementFactory.getThreadMXBean();
boolean cpuTimeSupported = threadBean.isCurrentThreadCpuTimeSupported();
Random random = new Random();
for (int i=0; i<5; i++) {
int targetDuration = 100 + random.nextInt(900);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is your target duration randomly choosen ?
From what I've been taught this is not really a good practice in unit testing.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there anything in particular you're thinking of?
I'd say the benefit is that it covers a wider range of inputs. The downside is that test failures are harder to reproduce.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly what I mean.
Beside you're not tracking the currently choosen value.

One thing you could do is running the two tests : one with a fixed value and another randomly choosen.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have a point about the value not being logged. I'll add that.

int numIterations = SCrypt.timedIterations(targetDuration, 8, 1);
long startTime = cpuTimeSupported ? threadBean.getCurrentThreadUserTime() : System.nanoTime();
SCrypt.scrypt(passwd.getBytes(), salt, numIterations, 8, 1, dkLen);
long endTime = cpuTimeSupported ? threadBean.getCurrentThreadUserTime() : System.nanoTime();
long actualDuration = (endTime-startTime) / 1000000;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why you take a time in nano an divide it to a lower resolution ?
(femto if I'm correct)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above.

assertTrue(actualDuration>targetDuration*5/10 && actualDuration<targetDuration*16/10); // be generous

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is hard to read.
Can you confirm me that your trying to assert that the actual duration is within targetDuration - 50% and targetDuration + 60%

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's correct. I'll see if I can make it easier to understand.

}
}
}