<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 31, 2016 at 3:10 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nice, looks like a good parsing setup.<br>
<br>
Also a good step towards a Python library, security analysis tool<br>
(e.g. generating "Security Property" tables), or code-generation tool.<br></blockquote><div><br></div><div>I did start to write a "Security Properties" script but my brain melted at reverse-engineering the sequence of tokens that leads to each of the 1-5 levels in the specification.  You might have better luck (I can send you what I have so far which isn't much).  A deterministic set of token classification rules for security properties would be nice.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Code-gen would be particularly useful, Noise adopters so far are<br>
preferring simple "compiled" -code rather than general libraries.<br>
<br>
I feel like you could get pretty far just with per-language files<br>
containing some text templates, but I'm sure devil's in details...<br></blockquote><div><br></div><div>I did think about that.  One "devil" is the back end crypto primitives - the API's for those are all over the map with no consistency.  But if that can be pushed off to a plug-in class/template, then it may be doable.<br><br></div><div>Cheers,<br><br></div><div>Rhys.<br><br></div></div></div></div>