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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 20 November 2015 16:16 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269791B35E1 for <secdir@ietfa.amsl.com>; Fri, 20 Nov 2015 08:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEnyUrK2HDuT for <secdir@ietfa.amsl.com>; Fri, 20 Nov 2015 08:16:28 -0800 (PST)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA381B35B0 for <secdir@ietf.org>; Fri, 20 Nov 2015 08:16:27 -0800 (PST)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with comcast id jsG41r0052N9P4d01sGTEk; Fri, 20 Nov 2015 16:16:27 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id jsGR1r0113KdFy101sGRFU; Fri, 20 Nov 2015 16:16:27 +0000
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Simon Josefsson <simon@josefsson.org>
References: <55DCB0A2.5050102@alum.mit.edu> <87d1v4hn1h.fsf@latte.josefsson.org> <564F3AB9.7060400@cs.tcd.ie>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <564F4758.3020200@alum.mit.edu>
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: <564F3AB9.7060400@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1448036187; bh=UPlv3J4yNI1BjLT8Mo1ueSp2N6qFMIv02GvtGDIOiUw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gqBl1ODmeg+x3U3gMeD+OMJ5/QhZ8SP/SOnenWqT8YK6uQ51s+Y/4g9TCMsMIjL/C KxVm+VwhziLUJOpqy3gRfSGW5jbEMM06+CFS0o6W2af8ua8dPKnpgIfKU05SvskjTE MaKKeAirVI4JQFxFC/8xEttyM+cBsHBe3Z8MsR62Wa22DLmOvtdYuvt4GPhN5VcCu2 pKDw6TEe6RVxqOR+uwE9O931/7NTrTVCEYZSdxiCj3zVEyCTiPI6hw5yofp57GOlLo /PnnHwJ4FHn3W47WB7AiKnr9FsbVrUbTJ3rzG1vGQzjONkb5l+q9sjLoxPlEZIxY4w kOrFXJqw5AumA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/zsIf5w7K28Wqz8Zl2cFHmu0FnME>
Cc: draft-josefsson-scrypt-kdf.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Gen-ART Last Call review of draft-josefsson-scrypt-kdf-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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 
needed.

	Thanks,
	Paul