Re: [Gen-art] Gen-ART Last Call review of draft-josefsson-scrypt-kdf-03

Paul Kyzivat <> Fri, 20 November 2015 16:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 267861B35C8 for <>; Fri, 20 Nov 2015 08:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UmhAe3H-I-Eq for <>; Fri, 20 Nov 2015 08:16:28 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1166E1B35C1 for <>; Fri, 20 Nov 2015 08:16:28 -0800 (PST)
Received: from ([]) by with comcast id jsFE1r0042N9P4d01sGThX; Fri, 20 Nov 2015 16:16:27 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id jsGR1r0113KdFy101sGRFU; Fri, 20 Nov 2015 16:16:27 +0000
To: Stephen Farrell <>, Simon Josefsson <>
References: <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Fri, 20 Nov 2015 11:16:24 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1448036187; bh=UPlv3J4yNI1BjLT8Mo1ueSp2N6qFMIv02GvtGDIOiUw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BNauFb9fFdlZEb7wmQdgFKV7UY7lh4V78C4DWubqdoQJxRz4nWv8XE1dhg3fG9SLC Esi9boDZzeGolENyG3xWshdwsu/PKFG6VvrIGCZSDmFSruZlI8eUmjzL4Wj35YW39u FeUt0utHxwAGDh0YvVXe8Sw8QxB1Tqlj4bJy5hQAO2e3mOfNpfTL3HEmlMFAvTSPCc l75fckD3vFhNhBsGMyn4Bq9ji60KDLQgRAV6nUbOMBOhKokU3XcsUyujVfjNb/Xajm 5iejBQ6bZRwyXnJE2pzS1ZCRc2bklMdCe8jIa05cUmfNs7qJ2xQT/Gzk7uzA7I7SCc tazZRpXHe7mtw==
Archived-At: <>
Cc:, General Area Review Team <>,,
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-josefsson-scrypt-kdf-03
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2015 16:16:29 -0000

I did want to comment on one other thing:

 >>> (Issue-4): Identifiers reused for different meanings
>>> In scrypt, "B" is an array of "p" vectors, each of which is 128*r
>>> octets. In scryptROMix, "B" is a single vector of 128*r octets. In
>>> scryptBlockMix, "B" is a vector of 2*r 64-octet blocks.
>> I'm not sure that changing variable names here is a good idea.  For any
>> performant implementation, these variables will refer to the same memory
>> area and thus a consistent variable name helps to signal that.  It is
>> just the interpretation of that memory area that is different in these
>> functions.

>>> The document would be clearer if distinct identifiers were used for
>>> each unique concept.
>> I believe the identifier refers to unique concepts.  For B, what differs
>> is how that memory area is interpreted in each algorithm description.

I don't think it works for a *spec* to assume that a "memory area" can 
be interpreted differently, sometimes as a number, sometimes as an array 
of bytes, sometimes as an array of arrays, etc.

Making such assumptions depends on the language being used mapping these 
things to the same memory in a consistent way. Some languages don't 
allow this at all, and those that do often lay out memory with padding 
for efficiency, according to little/big endianness, etc.

So I think it is important to clearly define any type coercions that are