[noise] dissononce, idea and a question

[Trevor Perrin]

Nice!, looks very clean, and you're doing some interesting things with
handling modifiers programmatically.

I've added it to Wiki:

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

It appears you're passing the cacophony test vectors?  Given that, our
typical process is to let people review and test for a couple months
to make sure it's mature, and then link it from the main
noiseprotocol.org website, so that seems like a good approach here.

Trevor

On Wed, Apr 17, 2019 at 1:31 PM Tarek Galal <tare2.galal at gmail.com> wrote:
>
> Hi Noise,
>
> I published dissononce; a python implementation for Noise based on revision 34. I'm aware of Piotr's also python implementation, 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 which fail and this is cryptography's key exchange docs 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!
>
>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise