[noise] Python 3 implementation released

[Trevor Perrin]

On Tue, Sep 12, 2017 at 8:19 PM, Piotr Lizończyk <piotr.lizonczyk at gmail.com>
wrote:

> Hello noisy people!
> Some minutes ago, I've finally published the Python 3 implementation of
> Noise Protocol Framework.
>
> The code is available here: https://github.com/plizonczyk/noiseprotocol
> and it is also available in PyPI: https://pypi.python.org/
> pypi/noiseprotocol
>


Hi Pieter,

Glad to see this!  I linked it on the wiki:

https://github.com/noiseprotocol/noise_wiki/wiki

Once it's been looked over and tested more I'll link it from the website.


Quick feedback:

 * 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.

 * 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.

 * About names:
   - The "Builder" terminology seems a little off since the Builder object
is used directly as the main interface.
   - Names "ed25519" and "ed448" normally either refer to a signature
algorithm or Edwards-form curve, maybe just use "X25519" or "25519"?
   - File names "functions.py" and "crypto.py" and "state.py" aren't very
obvious as to what they contain.

 * 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).

 * 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?

 * Seems like the crypto code could also be reorganized so it's easier to
plug in different back-end implementations?

 * 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.

 * 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:
https://github.com/trevp/tlslite/blob/master/tlslite/utils/compat.py

Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170914/01f7bc49/attachment.html>