[noise] Noise Explorer: Generate Software Implementations

Wed Jan 30 18:00:34 PST 2019

Hi Nadim,

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:

Noise_XXhfs_25519+Kyber_ChaChaPoly_Blake2b

where the usage of the "hfs" protocol modifier is described here:

https://github.com/noiseprotocol/noise_wiki/wiki/Hybrid-Forward-Secrecy

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:

https://github.com/katzenpost/noise

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!

Best,
David

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 [0] 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 [1].
> 
> As always, you may try out Noise Explorer here:
> https://noiseexplorer.com/
> 
> 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
> JavaScript, while still being safer than for example C.
>     - 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 [2] 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
> implementations.
>     - 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:
> https://github.com/SymbolicSoft/noiseexplorer/issues
> 
> I hope Noise Explorer will continue to be useful to the world!
> 
> References:
> [0] https://www.youtube.com/watch?v=ZrcdDJhbPKQ
> [1] https://golang.org
> [2] http://hackage.haskell.org/package/cacophony
> 
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from office

> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20190131/5fded45c/attachment.sig>