CRYPT rounds vs. performance

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CRYPT rounds vs. performance

whoami toask
I tested OpenBSD 5.6 in VirtualBox on a RHEL 6.5 Workstation, T410:

A few installs, with full disc encryption, only the rounds differ
the guests had: 2 GB RAM, fixed 10 GB HDD, same 10 char pwd, i5 CPU M 560:
(I placed dots only for better reading, not in the real command)

        A = bioctl -r 1.000 -c C -l /dev/sd0a softraid0
        B = bioctl -r 100.000 -c C -l /dev/sd0a softraid0
        C = bioctl -r 1.000.000 -c C -l /dev/sd0a softraid0
        D = bioctl -r 10.000.000 -c C -l /dev/sd0a softraid0
        E = without encryption

I did a:

        dd if=/dev/zero of=test.foo

on them:

        A = ~107 sec
        B = ~105 sec
        C = ~109 sec
        D = ~106 sec
        E = ~110 sec
-> ~22 MB/s

From the man pages:

-r rounds
        When creating an encrypted volume, specifies the number of iterations of
        the PBKDF2 algorithm used to convert a passphrase into a key. Higher iteration
        counts take more time, but offer more resistance to key guessing attacks. The
        minimum is 1000 rounds and the default is 8192.

---------------------------
Questions for the community/devs:

- Are there any statistics for comparing the rounds vs. the time for one password to "crack"? What is the best* round number?

*- Does the rounds affect the disk performance, ex.: 1000 vs. 10 000 000**? OR it just ONLY affects the time until the password unlocks the CRYPT device?

**When I used 10 000 000 rounds, after giving the pwd at boot, it took ~30 seconds to start the real boot

It looks like using dd didn't do any difference between encrypted vs. not-encrypted disks.. so was my tests bad?

Thank you,

Reply | Threaded
Open this post in threaded view
|

Re: CRYPT rounds vs. performance

Andy Bradford-21
Thus said "whoami toask" on Sat, 03 Jan 2015 17:18:04 -0500:

> *- Does the  rounds affect the disk performance, ex.:  1000 vs. 10 000
> 000**? OR it just ONLY affects the time until the password unlocks the
> CRYPT device?

Yes, unless  I'm mistaken, it really  only affects how long  it takes to
generate the  key from the  passphrase. Once the  key is in  memory, the
number of rounds is no longer really relevant.

Also, one of  the primary reasons for having salts/rounds  is to protect
against  offline attacks  against  the password  database (e.g.  someone
obtains /etc/master.passwd and begins to hash passwords until a match is
found) using rainbow tables. With random  salts and large rounds it will
be extremely prohibitive to crack all the passwords in the database.

In the case  of an encrypted volume, however, we  aren't talking about a
password database  with all kinds of  usernames/passwords. We're talking
about a  single key derived  from a passphrase which  means salts/rounds
don't  have the  same  implications as  they do  for  an offline  attack
against a database. In this case, it would seem that the best protection
is a larger  number of rounds (bioctl defaults to  8192 according to the
man page).

Andy
--
TAI64 timestamp: 4000000054a881c2

Reply | Threaded
Open this post in threaded view
|

Re: CRYPT rounds vs. performance

whoami toask
In reply to this post by whoami toask
So this is like SSH, where I could increase the KEY size without affecting the bandwidth? If using big SSH KEY's, that would ONLY mean slower logins? Similar as using bigger rounds on an OpenBSD CRYPTO devices?

Thank you!

-------- Original Message --------
From: "Andy Bradford" <[hidden email]>
Apparently from: [hidden email]
To: "whoami toask" <[hidden email]>
Cc: [hidden email]
Subject: Re: CRYPT rounds vs. performance
Date: 3 Jan 2015 16:56:15 -0700

> Thus said "whoami toask" on Sat, 03 Jan 2015 17:18:04 -0500:
>
> > *- Does the  rounds affect the disk performance, ex.:  1000 vs. 10 000
> > 000**? OR it just ONLY affects the time until the password unlocks the
> > CRYPT device?
>
> Yes, unless  I'm mistaken, it really  only affects how long  it takes to
> generate the  key from the  passphrase. Once the  key is in  memory, the
> number of rounds is no longer really relevant.
>
> Also, one of  the primary reasons for having salts/rounds  is to protect
> against  offline attacks  against  the password  database (e.g.  someone
> obtains /etc/master.passwd and begins to hash passwords until a match is
> found) using rainbow tables. With random  salts and large rounds it will
> be extremely prohibitive to crack all the passwords in the database.
>
> In the case  of an encrypted volume, however, we  aren't talking about a
> password database  with all kinds of  usernames/passwords. We're talking
> about a  single key derived  from a passphrase which  means salts/rounds
> don't  have the  same  implications as  they do  for  an offline  attack
> against a database. In this case, it would seem that the best protection
> is a larger  number of rounds (bioctl defaults to  8192 according to the
> man page).
>
> Andy
> --
> TAI64 timestamp: 4000000054a881c2