Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2015 00:25:42 +0100

With apologies to the author/shepherd, I forgot about this one;-(

I'm going to start IETF last call now. My own comments below can
be handled with any other last call comments.

Cheers,
S.

- intro: Maybe take a look at the intro to RFC7539. I think
it does a good job of presenting the background (for a
similar DJB production:-) so it might be worth seeing if
there's anything you want to copy from that.

- intro, para 1: some more references (or one ref to a
survey paper) would be good

- intro, para 2: "as Bernstein pointed out" requires a
reference

- section 13: whassup with that? why isn't the usual IETF
boilerplate ok?

- section 16: saying the reader "must" follow crypto
research is silly as you cannot ensure readers will do that
(and you know they won't:-). I think you mean that if you
don't keep up to date then you might miss out when issues
are found with this algorithm. If so, saying so would be
better.

- 17: I'm not sure the RFC editor will like references that
only point to http://cr.yp.to/ or tarsnap.com. If you have
better citations in addition that'd be good.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Aug 2015 00:39:18 +0200

> be handled with any other last call comments.

Thank you!

The changes mentioned below are in this commit:
https://gitlab.com/jas/ietf-scrypt/commit/6f4f3335552528994ae326a4641b179d10a31e83#diff-1

> there's anything you want to copy from that.

I have added some text inspired by this.

> survey paper) would be good

I suppose you mean references for the following?

DES-based UNIX Crypt-function,
FreeBSD MD5 crypt,
GNU SHA-256/512 crypt
Windows NT LAN Manager (NTLM) hash
Blowfish-based bcrypt

I can try to find some references.  Help appreciated on what a good
reference for these would be, the FreeBSD/GNU/NTLM are proprietary and
may lack a good specification.  I did not make any change yet.

> - intro, para 2: "as Bernstein pointed out" requires a

I dropped this.  His NFS circuit integer factorization paper was
folklore 10 years ago but less so today.

> - section 13: whassup with that? why isn't the usual IETF

You can't copy text from RFCs into FOSS code.  Section 13 gives reader
additional rights.  Similar boiler plate have been used in a couple of
RFCs already, and from what I understand is not in conflict with any
IETF procedures.

> are found with this algorithm. If so, saying so would be

I tried to rephrase it -- improvements welcome.

> better citations in addition that'd be good.

As far as I know, Salsa20 was not published at any conference or
journal, so there may not be any better references.

For the scrypt paper, maybe the conference homepage is better?  Instead
of tarsnap.com the scrypt paper would then be linked to this page:

https://www.bsdcan.org/2009/schedule/track/Hacking/147.en.html

I did not make this change yet.

/Simon

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 13 Aug 2015 13:48:39 +0200

> Windows NT LAN Manager (NTLM) hash

The latter was published in USENIX 1999:
https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf

> journal, so there may not be any better references.

Salsa20 was an official submission to estream competition, so the
authoritative reference is the design articles at:
http://www.ecrypt.eu.org/stream/salsa20pf.html (the "Salsa20
specification" and "Salsa20 design").

regards,
Nikos

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 13 Aug 2015 09:10:25 -0400

> specification" and "Salsa20 design").

I'd jut like to take a step back from the reference question to ask,
why is salsa used as a hash when it was designed as a stream cipher?
Is there a reason Blake2 (derived from chacha) was not used instead?
Maybe there is a good reason and I'd be interested to have that
background.

Thanks,
Kathleen

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

-- 

Best regards,
Kathleen

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Aug 2015 16:24:08 +0200

> why is salsa used as a hash when it was designed as a stream cipher?

This is a terminology issue.  'Salsa20 core' or 'Salsa20 hash' is
explained here:

http://cr.yp.to/salsa20.html

Salsa20 core is a hash function, in its general sense, see:

https://en.wikipedia.org/wiki/Hash_function

In particular, Salsa20 core is NOT a cryptographic hash function.
Compare Salsa20 core to FNV or CRC or something similar, not to SHA-1.

Salsa20 the stream cipher is based on the Salsa20 core hash function.

Scrypt does not use Salsa20 the stream cipher.

Think of the Salsa20 hash function as similar to FNV hash.

This said, I'm not convinced the estream Salsa20 specification is the
most suitable reference to explain the Salsa20 core hash function.  The
eSTREAM site linked above only appear to publish a ZIP file with the
algorithm specification.  Is that a good reference?  However, perhaps we
can add it as an additional reference?  Then there is always the worry
about which is the "right" one in case of differences, but since the
draft includes test vectors I doubt there will be any confusion.

> Is there a reason Blake2 (derived from chacha) was not used instead?

1) Scrypt needs a (fast) mathematic hash function, not a cryptographic
hash.

2) Age; ChaCha and Scrypt were designed at the same time.

> Maybe there is a good reason and I'd be interested to have that

I hope this helps.

/Simon

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 13 Aug 2015 10:35:53 -0400

>> Maybe there is a good reason and I'd be interested to have that

Thanks, I was just taking a quick look at this because of the reference problem.

-- 

Best regards,
Kathleen

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Aug 2015 16:40:19 +0200

> https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf

Thanks, I have added this reference:
https://gitlab.com/jas/ietf-scrypt/commit/3ec64578caeae390a2135eccd482e0e1659163c9

I recall a blog post from Ulrich Drepper describing the GNU libc
SHA-256/512 crypt function but cannot locate it now.

NTLM was discussed on this list recently, and it is a proprietary
algorithm and I'm not aware of any suitable reference for it.

/Simon

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 13 Aug 2015 20:30:04 -0400 (EDT)

> algorithm and I'm not aware of any suitable reference for it.

It has been a while since I was needing to refer to it from a document,
but I thought that https://msdn.microsoft.com/en-us/library/cc236621.aspx
was pretty canonical.

-Ben

---

From: ianG <[email-masked]>
Date: Fri, 14 Aug 2015 01:55:56 +0100

> most suitable reference to explain the Salsa20 core hash function.

Concur - the world has changed.  Review-by-web-page is now fairly well 
understood.  As it happens the most influential paper in the space was 
simply bandied around on a mail list for a while.  You could say, it was 
reviewed by running code and rough consensus!  He'll probably end up 
with the first pseudonymous Turing prize.  Or she.  Or they.

iang

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 14 Aug 2015 07:07:58 +0200

> but I thought that https://msdn.microsoft.com/en-us/library/cc236621.aspx

Thanks -- that appears similar to a cr.yp.to link, maybe somewhat worse
since it doesn't mention an author and the content appears to change
frequently and I can't find links to a stable version of the document.
I'll use it and let Stephen and/or the RFC editor figure out how to
handle this.  I agree with ianG that the world has changed here, and it
should be fine to use URLs like this when there isn't any better
alternative available.

https://gitlab.com/jas/ietf-scrypt/commit/306d3e8a6d67d9118c6907a5544baa79ccf76f1d#diff-1

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Aug 2015 12:32:10 +0100

On 14/08/15 06:07, Simon Josefsson wrote:
> I agree with ianG that the world has changed here, and it

Using URLs is fine, and sometimes the best that can be done.

I think the RFC editor are reasonably enough concerned that
bitrot does kick in and they, and we, do like that decades
old RFC references can still be de-referenced.

So in general I think it's reasonable to question any case
where the only reference is via a URL hosted on a domain
that one considers might not be there in 20 years. And having
asked the question, it can also be reasonable to just use
such a URL if that's the best there is.

S.