[noise] Machine-readable pattern list

Rhys Weatherley rhys.weatherley at gmail.com
Wed Oct 5 01:30:50 PDT 2016


On Wed, Oct 5, 2016 at 4:01 PM, Trevor Perrin <trevp at trevp.net> wrote:

> Maybe, but if the only benefit here is that a tool that works with
> text patterns can avoid scanning for "...", that's not that much of a
> gain.
>
> There's not that much cost to this proposal either.  But the visual
> appearance would be a little messier (we're indicating the same
> information 2 different ways).
>

I'd argue that it is not the same information.  Pre-message tokens come
from a more restrictive set ("e", "f", and "s" only) and can only occur in
certain orders.  The grammar can enforce these rules if it knows early
enough.

It is possible to write an LALR(1) parser in Bison with the same arrows for
both (I know because I just did so) but to avoid reduce/reduce conflicts it
is necessary to optimistically parse the pre-messages as full messages and
then later go back during semantic analysis to eliminate bad pre-messages
and messages.  With double-arrows, the grammar can enforce the rules in one
pass.

I can live with it either way I suppose, but the more context-free the
better from a langsec point of view.

ABNF for the grammar is appended.  Basic tokens only, no hybrid.  Extending
it to hybrid tokens is obvious.

Also, currently you can think of "->" and "<-" as arrows, rather than
> text, and I've done this sometimes:
>
> https://noiseprotocol.org/docs/noise_stanford_seminar_2016.pdf
>
> With "=>" notation this isn't as easy - you'd need a fat and skinny
> arrow, or an arrow with two tails?
>

Unicode has lots of arrows to choose from for fancy presentations. :-)

https://en.wikipedia.org/wiki/Template:Unicode_chart_Arrows

Cheers,

Rhys.

---- ABNF ----
; Defined using the ABNF syntax from RFC 5234.  The character set is
US-ASCII.
;
; The "pattern-file" element is intended for a pattern dictionary file that
; contains multiple pattern definitions.
;
; The "pattern-single" element is intended for applications that wish to
; provide an API to define the specific pattern to use in a handshake.

; Syntactic elements

pattern-file        = *(wsp pattern) wsp

pattern-single      = wsp pattern wsp

pattern             = header wsp [pre-message wsp] messages

header              = name wsp "(" wsp params wsp ")" wsp ":"

params              = param *(wsp "," wsp param)

param               = "e" / "s" / "re" / "rs"

pre-message         = pre-message-init [wsp pre-message-resp] wsp "..." /
                      pre-message-resp wsp "..."

pre-message-init    = "=>" wsp pre-message-tokens

pre-message-resp    = "<=" wsp pre-message-tokens

pre-message-tokens  = "e" / "s" / "e" wsp "," wsp "s"

messages            = *(message-pair wsp) message-init / message-pair

message-pair        = message-init wsp message-resp

message-init        = "->" wsp message-tokens

message-resp        = "<-" wsp message-tokens

message-tokens      = message-token *(wsp "," wsp message-token)

message-token       = "e" / "s" / "ee" / "ss" / "se" / "es"

; Lexical tokens

name                = "Noise_" name-component *("+" name-component)

name-component      = 1*(ALPHA / DIGIT)

wsp                 = *(WSP / eol / comment)

comment             = "//" *(VCHAR / WSP) eol

eol                 = CRLF / LF

; Imported from core ABNF (RFC 5234): VCHAR, WSP, CRLF, LF, ALPHA, DIGIT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20161005/53f1aa66/attachment.html>


More information about the Noise mailing list