[noise] dissononce, idea and a question

[Tarek Galal]

Hi Noise,

I published dissononce <https://github.com/tgalal/dissononce>; a python
implementation for Noise based on revision 34. I'm aware of Piotr's also
python implementation <https://github.com/plizonczyk/noiseprotocol>, which
is great and a very helpful reference. However I had a slightly different
idea for what a python implementation for Noise could look like.

- I went for pushing and preferring a more verbose composition-style of
Noise Protocols rather than resolving using string names.
- It's intended by this implementation to also be a simple to understand
practical reference to Noise spec, therefore the library tries to segregate
Noise spec implementation from any own features of the lib.
- A verbose package structure to ease navigation for someone learning about
Noise.
- Implementations for crypto algorithms are organized under
stable/experimental/dangerous categories.
- Flexible Pattern modifiers; a Pattern Modifier modifies a given Handshake
Pattern rather than a Handshake Pattern modifying itself based on a given
Pattern Modifier's name.
- Access to underlying crypto primitives and providers is abstracted,
resulting in crypto backend flexibility where an explicitly defined backend
is unnecessary.
- No limitations imposed by the library itself on supported python
versions. It's up to underlying dependencies which at the moment happily
work on python 2.5-3.7

code on github: https://github.com/tgalal/dissononce
published on pypi: https://pypi.org/project/dissononce

Side note: I think the concepts of defining, modifying and processing
tokens could be done in a kind of more "autonomous" way where a defined
token also has some associated "token processor" defined. The token
processor is then what takes care of updating the HandshakeState depending
on the token's meaning. This kind of separation between token processing
and HandshakeState could allow for flexibility adopting new (and
experimental) tokens, even those which don't officially exist Noise spec,
without having to diverge HandshakeState implementations from the official
spec in order to include processing rules for those tokens.
Implementation-wise I'm still thinking of the How as this might introduce
complexities understanding the code which I'd like to avoid. Anyways, only
an idea for now.

Finally a question; I was trying to plug in a DH functions implementation
based on pynacl when I found that the shared secrets it calculates are not
consistent with those produced by cryptography lib (uses OpenSSL v1.1 as
backend I believe) for the same keypairs and of course fail the tests. I'm
not a cryptographer myself so it's a bit hard to pin point the exact
reason. This is pynacl's docs about shared secrets
<https://pynacl.readthedocs.io/en/stable/public/#nacl-public-box> which
fail and this is cryptography's key exchange docs
<https://cryptography.io/en/latest/hazmat/primitives/asymmetric/x25519/#x25519-key-exchange>
which succeed the tests. I'd appreciate any hints as it would be great if I
could consider this in dissononce's design and docs.

Feedback is very welcome, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20190417/458d2679/attachment.html>