[noise] dissononce, idea and a question

[Tarek Galal]

Thanks! Yes, cacophony and snow's multipsk set.

Trevor Perrin <trevp at trevp.net> schrieb am Do., 18. Apr. 2019, 05:46:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20190418/0243ee42/attachment.html>