<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 12, 2017 at 8:19 PM, Piotr Lizończyk <span dir="ltr"><<a href="mailto:piotr.lizonczyk@gmail.com" target="_blank">piotr.lizonczyk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello noisy people!<div>Some minutes ago, I've finally published the Python 3 implementation of Noise Protocol Framework.</div><div><br></div><div>The code is available here: <a href="https://github.com/plizonczyk/noiseprotocol" target="_blank">https://github.com/<wbr>plizonczyk/noiseprotocol</a></div><div>and it is also available in PyPI: <a href="https://pypi.python.org/pypi/noiseprotocol" target="_blank">https://pypi.python.org/<wbr>pypi/noiseprotocol</a></div></div></blockquote><div><br></div><div><div><br></div><div>Hi Pieter,</div><div><br></div><div>Glad to see this!  I linked it on the wiki:</div><div><br></div><div><a href="https://github.com/noiseprotocol/noise_wiki/wiki">https://github.com/noiseprotocol/noise_wiki/wiki</a></div><div><br></div><div>Once it's been looked over and tested more I'll link it from the website.</div><div><br></div><div><br></div><div>Quick feedback:</div><div><br></div><div> * The API looks clean and simple and the core logic (in state.py) looks clear.  I'd like to review more (and hear other reviews) but looks like a solid foundation.</div><div><br></div><div> * There's test vectors linked from Wiki, it would be great to make sure this passes the "cacophony" and maybe "snow-multipsk" sets.  Cool that you have a WireGuard demo/test.</div><div><br></div><div> * About names:</div><div>   - The "Builder" terminology seems a little off since the Builder object is used directly as the main interface.</div><div>   - Names "ed25519" and "ed448" normally either refer to a signature algorithm or Edwards-form curve, maybe just use "X25519" or "25519"?</div><div>   - File names "functions.py" and "crypto.py" and "state.py" aren't very obvious as to what they contain.</div><div><br></div><div> * You might want an API that handles choosing PSKs during the handshake (e.g. if a WireGuard server looks up the PSK based on the client's identity).</div><div><br></div><div> * The DH code seems like it could be better organized / refactored somehow.  E.g. right now there's separate DH and KeyPair objects, and the KeyPair has an inheritance hierarchy but the DH doesn't?  </div><div><br></div><div> * Seems like the crypto code could also be reorganized so it's easier to plug in different back-end implementations?</div><div><br></div><div> * The comments in Cipher class seem right that you could avoid initializing a cipher object for every encryption, which might be inefficient for AES-GCM.</div><div><br></div><div> * When I used to write Python crypto I handled 2 and 3 with a compatibility layer, you're welcome to adapt that but your library uses enough 3 features that it might not be easy:</div><div><a href="https://github.com/trevp/tlslite/blob/master/tlslite/utils/compat.py">https://github.com/trevp/tlslite/blob/master/tlslite/utils/compat.py</a></div><div><br></div></div><div>Trevor</div><div><br></div></div></div></div>