Subject: [saag] New I-D: Password Storage Using Public Key Encryption

From: Robert Kisteleki <[email-masked]>
Date: Sun, 08 Dec 2013 16:51:30 +0100

Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Mon, 9 Dec 2013 09:38:15 +0000

Hi,

thanks for the I-D. Interesting idea. It solves some (but not all) problems
of password authentication. I have some questions about the advantages of
your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple
rounds of hashes (100x or 1000x).

How many hash rounds would be sufficient to make it equally secure compared
to your proposal (public key encryption)? (My gut feeling says 10.000
sha512 are more expensive than 1x 2048 rsa encrypt but I do not have
figures in front of me. Both algorithms are available in hardware [gpu,
verilog, ..]).

What is the advantage of your I-D compared to just increasing the hash
rounds?

regards,

ralf

On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Dec 2013 11:02:13 -0500

I may be misunderstanding things, but when I read the document, it seemed
like the number of rounds didn't actually matter.  As long as people use a
relatively fixed set of choices for the number of rounds (say 10, 100,
1000), an attacker can build a rainbow table for that number of rounds.  It
may be 10x / 100x / 1000x more expensive to build that table, but it may
also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x
is not a huge number anyway).

So if I'm understanding things correctly here, the mitigation would be to
have a large *and* *randomized* number of rounds.  Which seems like more of
a hassle to manage than Robert's proposal.

--Richard

On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser <[email-masked]> wrote:

> Hi,
>
> thanks for the I-D. Interesting idea. It solves some (but not all)
> problems of password authentication. I have some questions about the
> advantages of your I-D compared to the current work around that you mention:
>
> How many hash rounds would be sufficient to make it equally secure
> compared to your proposal (public key encryption)? (My gut feeling says
> 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not have

---

From: Robert Kisteleki <[email-masked]>
Date: Mon, 09 Dec 2013 17:19:57 +0100

On 2013.12.09. 17:02, Richard Barnes wrote:

> also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x is
> not a huge number anyway).
> 

Indeed that's the case. One can even reuse the same tables for cracking
multiple password databases, if they share the same amount of rounds. Hardly
anyone changes these settings to, say, 8563.

Robert

> On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not
>     have figures in front of me. Both algorithms are available in hardware
>     [gpu, verilog, ..]).
> 
>     On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hello,
> 
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Dec 2013 11:31:59 -0500

If this proposal includes a salt with the password that is encrypted, 
and the salt
is per user, and stored in the password table, as is common for hashed 
password tables,
then how does an atacker amortize the cost of the processing over 
multiple sites,
or even multiple users at the same site?

A rainbow table doesn't work against salted passwords, right?

Steve

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Mon, 9 Dec 2013 16:48:47 +0000

Hi,

not possible to build a rainbow table if salts are used (unless the salts
are to small).

Increasing the salts to say 64 bit would make it pretty hard to generate a
rainbow table (it would be 2^64 times more expense than not using salts).

yes, 1000x SHA1 can be optimized in HW but so can RSA_encrypt.

I have the feeling that 1000x SHA512 is more expensive than RSA_encrypt and
thus a 64 bit salt + 1000x SHA512 might (at the current time) provide
better security and is surely easier to implement/roll-out?! Just a
thought....

regards,

ralf

---

From: Paul Lambert <[email-masked]>
Date: Mon, 9 Dec 2013 10:28:58 -0800

Hi,

not possible to build a rainbow table if salts are used (unless the salts are to small).
Yes.  So it seems unnecessary to introduce public key into the hashing process if the salt is large enough.

However,  why are we making such changes to support the continued use of shared symmetric secrets for authentication.  Why not just store and use public keys?

Paul

Increasing the salts to say 64 bit would make it pretty hard to generate a rainbow table (it would be 2^64 times more expense than not using salts).

I have the feeling that 1000x SHA512 is more expensive than RSA_encrypt and thus a 64 bit salt + 1000x SHA512 might (at the current time) provide better security and is surely easier to implement/roll-out?! Just a thought....

regards,

ralf

On Mon, Dec 9, 2013 at 4:02 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
I may be misunderstanding things, but when I read the document, it seemed like the number of rounds didn't actually matter.  As long as people use a relatively fixed set of choices for the number of rounds (say 10, 100, 1000), an attacker can build a rainbow table for that number of rounds.  It may be 10x / 100x / 1000x more expensive to build that table, but it may also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x is not a huge number anyway).

So if I'm understanding things correctly here, the mitigation would be to have a large *and* *randomized* number of rounds.  Which seems like more of a hassle to manage than Robert's proposal.

--Richard

On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

thanks for the I-D. Interesting idea. It solves some (but not all) problems of password authentication. I have some questions about the advantages of your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple rounds of hashes (100x or 1000x).

How many hash rounds would be sufficient to make it equally secure compared to your proposal (public key encryption)? (My gut feeling says 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not have figures in front of me. Both algorithms are available in hardware [gpu, verilog, ..]).

What is the advantage of your I-D compared to just increasing the hash rounds?

regards,

ralf

On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Regards,
Robert

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

---

From: Christian Huitema <[email-masked]>
Date: Mon, 9 Dec 2013 19:05:03 +0000

> However,  why are we making such changes to support the continued use of shared symmetric secrets for authentication.  Why not just store and use public keys?

Well, the alternative is to keep not improving password based security in the hope that sites will just switch to something else. I am not holding my breath...

>> yes, 1000x SHA1 can be optimized in HW but so can RSA_encrypt.

Doing the same thing a fixed number of times does not really hampers a massively parallel attack. Yes, many iterations make every attempt is slower, but they can still be accelerated. To really slow the attacker, you need something much more varied, something that breaks vector pipelines and GPU implementations. For example, a test and a branch inside the inner loop, which really harms GPU implementation. Or a variable combination of multiple algorithms, which explodes the size of hardware implementations. 

-- Christian Huitema

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Mon, 9 Dec 2013 19:21:14 +0000

Hi,

On Mon, Dec 9, 2013 at 7:05 PM, Christian Huitema <[email-masked]>wrote:

> > However,  why are we making such changes to support the continued use of
> shared symmetric secrets for authentication.  Why not just store and use
> public keys?
>
> Well, the alternative is to keep not improving password based security in
> the hope that sites will just switch to something else. I am not holding my
> breath...
>

Correct. It wont happen in the near future. In the meantime let's improve
password security. The goal is to make dictionary/rainbow attacks more
expensive.

>
> >> Increasing the salts to say 64 bit would make it pretty hard to
> generate a rainbow table (it would be 2^64 times more expense than not
> using salts).
> Doing the same thing a fixed number of times does not really hampers a
> massively parallel attack. Yes, many iterations make every attempt is
> slower, but they can still be accelerated. To really slow the attacker, you
> need something much more varied, something that breaks vector pipelines and
> GPU implementations. For example, a test and a branch inside the inner
> loop, which really harms GPU implementation. Or a variable combination of
> multiple algorithms, which explodes the size of hardware implementations.
>
>
The cost increase is linear for all suggested solutions. Unless the
solution increases the cost exponentially there is no real benefit to using
a large salt and 10.000x SHA512. Comments welcome.

regards,

skyper

---

From: Christian Huitema <[email-masked]>
Date: Mon, 9 Dec 2013 19:46:41 +0000

>The cost increase is linear for all suggested solutions. Unless the solution increases the cost exponentially 
> there is no real benefit to using a large salt and 10.000x SHA512. Comments welcome.

The salt has to be large enough to make rainbow tables unpractical. In the age of big data, the bad guys too can use terabytes of storage. "Use 64 random bits of salt" looks like a very practical recommendation.

The linear increase of "N times SHA512" does slow down the attacker. It will take N times longer for the attacker to try their dictionary, and that will give N times more time for potential victims to be notified and change their passwords. The problem is that doing this also makes password verification slower, so we end up with a balance between performance and security. Make N too large and the performance are not acceptable. Make N too small and the attacker just have to use N times more resource.

I think the algorithm should be specifically designed to thwart GPU implementations, i.e. SIMD parallelism. You can get that by having variable number of steps, a random mix of SHA512 and SHA1 and even MD5, specifiying branching inside the inner loop, etc.

-- Christian Huitema

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 09 Dec 2013 12:07:55 -0800

As a side note, that's unfortunate that the iteration count N in popular 
iterative hashed password algorithms has an incremental property. This 
is true for PBKDF2 and OpenPGP string-to-key, for example.

By this I mean that to go from N to N+1 one only needs to do one hashing 
(and not N).

In practice N will not be entirely random, but a predictable range.

This is not an issue for random salts, but there is no reason why N 
should not be "hashed" as part of the derivation algorithm.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Dec 2013 10:06:36 -0500

Ralf,
> ...
> solution increases the cost exponentially there is no real benefit to 
> using a large salt and 10.000x SHA512. Comments welcome.
I don't agree that a linear cost increase is not worth pursuing, if the 
muyltiplier is big enough. Attackers have to spend money to perform 
password searches on hashed/encrypted password tables that they acquire. 
If we increase the cost by 10^5, their costs increase accordingly. While 
one might argue that, in an academic context,
only an exponential increase merits publication, that it not the context 
for this
discussion.

Steve

---

From: "Scott R. Corzine" <[email-masked]>
Date: Mon, 9 Dec 2013 14:02:02 -0500

What if you were to randomly generate the number of rounds and then save it
as we currently do for a salt?  For implementations which provide for
specific storage of salt + hash but aren't flexible enough to accommodate
salt+rounds+hash you could use the kludge of using the last n bits (say 16)
of the salt to double as the number of rounds (or add say 1000 to it to
ensure a minimum number of rounds).

-Scott-

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 10 Dec 2013 16:19:15 +0000

Stephen,

On Tue, Dec 10, 2013 at 3:06 PM, Stephen Kent <[email-masked]> wrote:

> password searches on hashed/encrypted password tables that they acquire. If
> we increase the cost by 10^5, their costs increase accordingly. While one
> might argue that, in an academic context,

That's exactly my point. A linear cost increase is worth pursuing. I'm all
for it.

We discussed two proposals:
A. Using Public key to store passwords
B. Using 64 bit salt + 10.000x hash (or whatever number is best)

I proposed solution B as it is less complex with no (security)-disadvantage
over the proposed solution A.

My 'that's just linear comment' was regarding the two suggested items to
make B more secure. Suggested was:
1. use two hashing algorithms
2. use a branch-statement

Both (1. and 2.) are a linear increase in attack cost.

Both (1. and 2.) come at the cost of complexity. (bad)

Both (1. and 2.) would make GPU/FPGA implementations harder. (good!)

Item 1. means the attacker would have to double the hardware cost. (good!)
Item 2. insignificantly increases the attack cost (neutral).

My favorite is B. and I have not made up my mind if the extra complexity of
1. justifies the gained security. Comments welcome.

regards,

ralf

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 10 Dec 2013 20:02:57 +0000

That is an interesting scheme also. I am not sure if using encryption would offer more benefit than that scheme.
Additionally, depending on the rounds, someone could make the password guessing as hard as he wanted.

My question in this case would be, how many round-bits does someone need to approximately have the same overhead as an encryption operation.

Panos

From: saag [mailto:[email-masked]] On Behalf Of Scott R. Corzine
Sent: Monday, December 09, 2013 2:02 PM
To: Richard Barnes
Cc: IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption

What if you were to randomly generate the number of rounds and then save it as we currently do for a salt?  For implementations which provide for specific storage of salt + hash but aren't flexible enough to accommodate salt+rounds+hash you could use the kludge of using the last n bits (say 16) of the salt to double as the number of rounds (or add say 1000 to it to ensure a minimum number of rounds).

-Scott-

On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
I may be misunderstanding things, but when I read the document, it seemed like the number of rounds didn't actually matter.  As long as people use a relatively fixed set of choices for the number of rounds (say 10, 100, 1000), an attacker can build a rainbow table for that number of rounds.  It may be 10x / 100x / 1000x more expensive to build that table, but it may also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x is not a huge number anyway).

--Richard

regards,

ralf

Regards,
Robert

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 10 Dec 2013 20:18:10 +0000

Hi,

On my server (AMD Athlon(tm) 64 Processor 3500+)

openssl speed sha512 rsa2048

sha512 on 512 bit: 59768k / second
rsa2048 encrypt 9430 / second

59768 * 1024 / 9430 = 6490 SHA512 are as expensive as 1 RSA-2048_encrypt.

regards,

skyper

On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (pkampana) <
[email-masked]> wrote:

>  That is an interesting scheme also. I am not sure if using encryption
> would offer more benefit than that scheme.
>
> My question in this case would be, how many round-bits does someone need
> to approximately have the same overhead as an encryption operation.
>
>
>
> Panos
>
>
>
>
>
>
>
>
>
> *From:* saag [mailto:[email-masked]] *On Behalf Of *Scott R.
> Corzine
> *Sent:* Monday, December 09, 2013 2:02 PM
> *To:* Richard Barnes
> *Cc:* IETF SAAG
> *Subject:* Re: [saag] New I-D: Password Storage Using Public Key
> Encryption
>
>
>
> What if you were to randomly generate the number of rounds and then save
> it as we currently do for a salt?  For implementations which provide for

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 10 Dec 2013 20:29:26 +0000

Thank you Ralf.
So, for SH256 or SH512 16 bits could give approximately as much or more overhead as 2048-bit RSA. With SHA-3, maybe more might bits will be needed, but not necessarily to many more.

Again, the benefit of such a scheme is that by changing the rounds, the password guessing can be made harder. I am wondering if there is a benefit to using encryption over variable rounds. I can't see any, except possibly if the salt's last x-bits could not be assumed uniformly distributed.

Panos

From: Ralf Skyper Kaiser [mailto:[email-masked]]
Sent: Tuesday, December 10, 2013 3:18 PM
To: Panos Kampanakis (pkampana)
Cc: Scott R. Corzine; Richard Barnes; IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption

Hi,

regards,

skyper

On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>> wrote:
That is an interesting scheme also. I am not sure if using encryption would offer more benefit than that scheme.
Additionally, depending on the rounds, someone could make the password guessing as hard as he wanted.

Panos

From: saag [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Scott R. Corzine
Sent: Monday, December 09, 2013 2:02 PM
To: Richard Barnes
Cc: IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption

-Scott-

--Richard

ralf

Regards,
Robert

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Dec 2013 17:16:29 -0500

I did a slightly more thorough (though still anecdotal) comparison using
`openssl speed`.  The upshot is that one RSA-4096 operation is worth
~44,000 iterations of SHA1 or SHA2.

Algorithm        Ops       Sec     Ops/Sec
sha1         8166584      3.00  0.00000037
sha256       4309619      3.00  0.00000070
sha512       6191854      3.00  0.00000048
512rsa        110009      9.98  0.00009072
1024rsa        30557      9.90  0.00032398
2048rsa         5271      9.99  0.00189528
4096rsa          611      9.80  0.01603928

Of course, this doesn't account for hardware optimization of any of the
algorithms.

If you want to do the test on your favorite system (you'll have to add the
headings yourself):

openssl speed sha1 sha256 sha512 rsa 2>&1 \
>     | grep "64 size blocks\|private RSA's" \
>     | sed -e "s/^.*: //; s/ bit private RSA/rsa/; s/'s in//; s/s$//;" \
>     | perl -lane '$spo = $F[2] / $F[0]; printf "%-10s%10d%10d%12.8f\n",
$F[1], $F[0], $F[2], $spo;'
sha1         8166584      3.00  0.00000037
sha256       4309619      3.00  0.00000070
sha512       6191854      3.00  0.00000048
512rsa        110009      9.98  0.00009072
1024rsa        30557      9.90  0.00032398
2048rsa         5271      9.99  0.00189528
4096rsa          611      9.80  0.01603928

On Tue, Dec 10, 2013 at 3:29 PM, Panos Kampanakis (pkampana) <
[email-masked]> wrote:

>  Thank you Ralf.
>
> So, for SH256 or SH512 16 bits could give approximately as much or more
> overhead as 2048-bit RSA. With SHA-3, maybe more might bits will be needed,
> but not necessarily to many more.
>
>
>
> Again, the benefit of such a scheme is that by changing the rounds, the
> password guessing can be made harder. I am wondering if there is a benefit
> to using encryption over variable rounds. I can’t see any, except possibly
> if the salt’s last x-bits could not be assumed uniformly distributed.
>
>
>
> Panos
>
>
>
>
>
>
>
> *From:* Ralf Skyper Kaiser [mailto:[email-masked]]
> *Sent:* Tuesday, December 10, 2013 3:18 PM
> *To:* Panos Kampanakis (pkampana)
> *Cc:* Scott R. Corzine; Richard Barnes; IETF SAAG
>

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 10 Dec 2013 22:34:10 +0000

Hi,

> but not necessarily to many more.

I do not understand '16 bits could give...'.

If the SHA512 is done 6490 times then it takes as long as one 2048-bit RSA
encrypt (on my server)

I believe multiple SHA512 rounds is less complex to implement and I have no
reason to believe that it is less secure (My gut says its more secure. I
trust SHA512 _for this application_ more than RNG's, prime numbers and
factoring).

> if the salt’s last x-bits could not be assumed uniformly distributed.

You are right, there is also the 3. option of variable number of rounds
which I missed in my previous email:

1. use two hashing algorithms
2. use a branch-statement
3. Variable number of SHA512 rounds.

Item 1. doubles the attack cost (GPU, FPGA) at no extra (processing)-cost
for the user. It does add complexity.
Item 2. only slightly increases the attack cost.
Item 3. All attacks that would exploit be made harder by this would also be
equally made harder by using a random/semi-unique salt (say 64 bit) for
each password.

regards,

ralf

Panos

---

From: "Scott R. Corzine" <[email-masked]>
Date: Tue, 10 Dec 2013 21:28:03 -0500

Hi Folks,

I realize in my enthusiasm to contribute I skipped a whole lot of steps and
context, then thought about some refinements.  Mostly I'm pulling together
what I've seen others saying or what seems obvious.  I've added a little
opinion, thoughts, and glue from me in the corners.  Sorry, this is long
but I wanted to get what I was seeing into a whole.

This mostly focuses on mechanics which will be applied for num_rounds
iterations of various algorithms.  Other people are making the pros and
cons for doing this and how many rounds would be appropriate.  I'm trying
to keep aan eye on with an eye towards easing the ability to retrofit
existing protocols and software

(1) The number of rounds (num_rounds) really has to be variable as time
goes on.
------Any fixed number will be too much for some, too little for others,
and become outdated over the course of time.
------Even a "fixed" number is likely to get IETF recommendations to be
increased some years from now.  If we don't treat it as variable we'll risk
interoperability issues between old and new.

(2) Num_rounds needs to be stored and transmitted with the hash & salt.
------This affects protocols, APIs, storage formats, and existing software.
------Even when implementations can share an external configuration source
for num_rounds, they are going to want to increase it over time creating
the problem of old passwords having one value and new passwords having a
different value.

(3) How num_rounds was determined is mostly irrelevant as long as it's
available.  This makes the choice between random and static an
implementation/configuration choice on the generator.
------RFC recommended values, local administrative settings, user
specification, or randomly generated num_rounds all work without the
verifier needing to know to generation (except for my salt kludge below).

(4) Randomly generated num_rounds can be governed within a lower_bound to
upper_bound range.
------These can allow for recommended default values with local override.
------Arbitrary non-random values can be achieved by setting
lower_bound=upper_bound.
------This allows implementations to skip randomizing num_rounds or even
supplying the randomization code without affecting interoperability.

(5) A big issue now becomes how do we pass this additional num_rounds
information in protocols, APIs, storage, application code (passing around
passwords/hashes), etc.

(5a) The best option is of course to add num_rounds as its own distinct
field.
--------This works well for new protocols and extensible implementations.
--------It's going to be difficult to do this in many cases unless they are
alread

(5b) Next option is to concatenate or otherwise merge num_rounds with the
salt or hash.
--------This works well as long as the field sizes are extensible, mostly
treated as opaque, clear mappings can be defined, etc.
--------The semantics and capabilities are basically the same as 5a.
--------This requires all intermediaries to handle the
num_rounds+salt+password in an opaque manner and to support variable
lengths for salts/hashes.
--------Implementations with 5a & 5b designs are likely to interoperate
with a common interoperabiliy point.

(5c) The kludge: overload part of the salt to also convey num_rounds.
--------This is only for compatibility modes with existing implementations
that can't support either 5a or 5b.
--------This will produce inferior results to 5a or 5b, but will be
significantly better that their status quo.
--------Some alternatives like public keys are likely to be unavailable for
this class.
--------To preserve all current entropy in the salt we continue to generate
it as before then derive the num_rounds from it.
--------Num_rounds is therefore constrained and has to be calculated
according to a well known formula shared by all the parties.
--------One example: num_rounds=salt%(hival-lowval)+low_val.  A change from
last night's message.
--------Inside an enterprise (which is the scope of most passwords) this
could be done by storing the parameters in a directory service such as LDAP.
--------For each salt there will only be one num_rounds (for a given
formula, hival, and lowval) but different salts will have different,
non-independent num_rounds.
--------Custom rainbow tables will have to be generated for different
combinations of formula, hival, and lowval.
--------This is partially compatible with 5a&5b: As long as the password
hashes were generated on a 5c system (or another in compatibility mode) all
5a, 5b, & 5c systems will be able to use it to interoperate.
--------Yes, It's a kludge.  But that's often required when trying to give
older systems features not originally designed.

(5d) Like 5c but both num_rounds and base_salt are randomly generated, then
combined to produce real_salt.
--------Trades off some entropy in the salt for more flexibility in
num_rounds.

(6) Lastly, we can make num_rounds automatically scale over time for new
password generations.
------We just define a multiplier to the base lower_bound & upper_bound
(recommended or locally specified) that scales over time.
------Example: real_lower_bound=int(base_lower_bound * 2^((year-2014)/2)).
------Reasonable minimums and maximums will be required to deal with
incorrect clocks and the like.
------Newly generated hashes then will tend to grow automatically in
computational costs as machine capacity grows.

How does that look?  Did I miss anything in this part?

Thanks,
-Scott-

On Tue, Dec 10, 2013 at 5:34 PM, Ralf Skyper Kaiser <[email-masked]> wrote:

> I believe multiple SHA512 rounds is less complex to implement and I have
> no reason to believe that it is less secure (My gut says its more secure. I
> Item 3. All attacks that would exploit be made harder by this would also
> be equally made harder by using a random/semi-unique salt (say 64 bit) for
> each password.
>
> regards,
>
> ralf
>
>  Panos
>>
>>
>>
>>
>>
>>
>>

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 11 Dec 2013 10:36:38 +0100

(Trying again, my message failed to show up on the list in the past 12 hours...)

> 59768 * 1024 / 9430 = 6490 SHA512 are as expensive as 1 RSA-2048_encrypt.

While these are likely to be representative for your general purpose CPU,
GPU implementations are *much* more effective for hashing (I know, [citation
needed] ... maybe [1] will do)

If that's correct, your numbers on real life difference may be orders of
magnitude off.

Robert

[1]
http://en.wikipedia.org/wiki/Graphics_processing_unit#Stream_Processing_and_General_Purpose_GPUs_.28GPGPU.29

---

From: Robert Kisteleki <[email-masked]>
Date: Tue, 10 Dec 2013 21:30:28 +0100

Robert

[1]

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Wed, 11 Dec 2013 13:46:26 +0000

Hi,

the comparison was how much faster SHA512 is compared to RSA2048 regardless
of the platform/HW. (If i double my CPU power than SHA512 is still 6490
times faster than RSA2048 on my HW).

Data about RSA2048 and SHA512 speed on a GPU would be interesting but wont
change that multiple rounds of SHA512
can be as expensive as a single round of RSA2048.

In general we can assume that SHA512 is 4,000 - 20,000x faster than RSA2048
on most given HW.

I agree with Scott that the number of rounds should be variable with a
recommended value (say 6000 rounds for year 2014). Recommendation should be
that the number of rounds should double in accordance with Moor's law.

(btw, it's currently 1 round so we are making the attack 6000x more
expensive. Not bad to start with...).

regards,

ralf

---

From: "Hilarie Orman" <[email-masked]>
Date: Tue, 10 Dec 2013 11:25:53 -0700

>  Date: Tue, 10 Dec 2013 10:06:36 -0500
>  From: Stephen Kent <[email-masked]>
>  To: [email-masked]

>  Steve

It's because Moore's Law refuses to die, and that means that
parallelism will eat up linear factors.  In this case, changing the
algorithm to be parallel-unfriendly will be more effective than
changing the constants.  But maybe all the hardware will be so busy
mining BitCoins that no one will bother with password cracking
anymore.

Hilarie

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Dec 2013 11:19:07 -0500

...

> mining BitCoins that no one will bother with password cracking
touche'

Steve

---

From: Paul Lambert <[email-masked]>
Date: Wed, 11 Dec 2013 17:39:04 -0800

>How does that look?  Did I miss anything in this part?

I missed something, if you use a large random salt is your proposal useful?

Paul