[noise] Noise Explorer: Generate Software Implementations
dawuud at riseup.net
Wed Jan 30 18:00:34 PST 2019
When do you plan to make a rust code generator?
Do you have plans to add support for hybrid forward secrecy Noise
protocol extension to your software generator?
In particular I am interested in using Kyber, specifically in this way:
where the usage of the "hfs" protocol modifier is described here:
And one more thing; I'd like to repeat myself and say that Katzenpost is
essentially the only software in existence (that I know of) that uses a Noise protocol
with a PQ KEM in HFS mode. Yawning's fork of the flynn golang noise library is here:
I'd like for us to not be the only software project doing this AND having your software
generator support PQ KEMs in HFS mode is a great way to solve this problem!
On Wed, Jan 16, 2019 at 09:48:07PM +0100, Nadim Kobeissi wrote:
> Hello everyone,
> A central promise that I made during Real World Crypto last week  was
> that Noise Explorer would soon support generating software implementations.
> Well, I am now pleased to announce that Noise Explorer can generate
> software implementations for arbitrary Noise Handshake Patterns, written in
> Go .
> As always, you may try out Noise Explorer here:
> In the rest of this email, I will answer some questions which may be of
> interest to readers of this mailing list.
> Q1: Why did you choose Go?
> A1: I chose Go as the initial target for the following reasons:
> - Go is my favorite programming language and I think it's very
> enjoyable to write software in.
> - Go allows for the production of independent executable for a very
> wide variety of operating systems and architectures.
> - Go is definitely among the top languages (if not the top language)
> used in network applications where Noise would be relevant.
> - Go is a relatively simple language, which makes it ideal as the
> initial target for code generation.
> - An encouraging discussion occurred with Mr. Filippo Valsorda, the
> maintainer of Go's crypto libraries, during which he indicated a level of
> commitment to Go having a strong, maintained and modern stack of the
> cryptographic primitives necessary for Noise Protocols to work.
> - Go allows for constant time cryptography, unlike for example
> - Yes, I know that Go does not currently support erasing secrets from
> memory. I wish it did.
> Q2: Are future languages planned?
> A2: Yes. I plan to integrate the following languages:
> - WASM: This will allow for small, portable Noise Handshake Pattern
> modules to be usable within web applications. Go supports native
> compilation to WASM, so I predict that this WASM code generation will be
> supported soon and with minimal fuss.
> - Rust: The impressively strong type system of Rust will allow us to
> reason more about the properties and constraints of certain components of a
> Noise Handshake Pattern, such as for example the one-time usage of
> ephemeral keys. These type checks, which may be onerous to write by hand,
> will be good to generate automatically using Noise Explorer.
> - F*: Same as Rust, but even more checks as well as proofs on algebraic
> matters using Z3.
> Q3: Can I help integrate my own language?
> A3: You should be able to but you'll need to do some tinkering. Noise
> Explorer does indeed use a modular, template-based framework, but despite
> my attempts to clean it up as much as possible it's still fairly
> opinionated and sometimes arbitrary. You can try, and you will likely
> succeed, but you will need to decipher the templates yourself. Happily,
> it's not very hard to do so.
> Q4: Can I use these generated implementations in production today?
> A4: It appears to me that there likely exists no serious problems in
> today's generated Go code. I would advise to test them out first, however,
> and perhaps read the code closely, at least for the first couple of weeks.
> I have tested the generated code locally for only a few days so far. It
> does seem to pass the test vectors provided by Cacophony  but I am still
> working on more tests, with the assistance of an undergraduate student who
> has expressed interest in writing a full test suite for Noise
> Explorer-generated implementations. So: yes, my code looks good, but no,
> it's only existed for a few days and I don't know whether I can just tell
> you to roll it out inside your mission-critical flying ambulance airplane
> without first reading the generated code yourself.
> Q5: Will these implementations be updated to support Revision 35, 36, etc.
> of the Noise Protocol Framework?
> Q5: Yes.
> Q6: I noticed that I am constrained by these generated implementations to a
> single cipher suite. Why is that?
> A6: This is for no good reason. I will soon support specifying your own
> cipher suites. Right now, you are constrained only
> to 25519_ChaChaPoly_BLAKE2s. I chose this cipher suite because:
> - It uses very nice primitives across the board.
> - It is used by WireGuard.
> Q7: Any other future plans for Noise Explorer?
> A7: No. The only things I have on my plate are what was listed above:
> - WASM, Rust and F* support.
> - More comprehensive automated test suites for generated
> - Cipher suite support.
> - Keep everything up to spec with upcoming official revisions to the
> Noise Protocol Framework.
> All of the above points are tracked on GitHub:
> I hope Noise Explorer will continue to be useful to the world!
>  https://www.youtube.com/watch?v=ZrcdDJhbPKQ
>  https://golang.org
>  http://hackage.haskell.org/package/cacophony
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from office
> Noise mailing list
> Noise at moderncrypto.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Noise