[armon]

You are right, the communication is still unicast in nature. I should clarify to say that there isn't a persistent 1-to-1 communication, the nodes we gossip with are randomly selected on each interval. There is no connection or session establishment between peers.

I guess it depends on your definition of roll your own. We didn't invent AES-GCM or implement it. We are using the implementation shipped with the Golang stdlib.

[bascule]

Nobody is questioning whether AES-GCM is a good algorithm or not, however you are using AES-GCM as part of a hand-rolled transport encryption protocol, and this is what's worrisome. Designing a transport encryption protocol is a difficult endeavor, and it seems you have skipped most of the steps (e.g. replay attack prevention) but suggest that it's irrelevant because other parts of the protocol provide security (e.g. the SWIM state machine).

This makes your protocol difficult to audit: someone concerned about potential attacks can't just look at your protocol in isolation, but has to factor the underlying protocol state machine into the security of your transport encryption protocol.

[jimktrains2]

> There is no connection or session establishment between peers.

OK, so I'm not understanding why isn't a 1-to-1 message, nor why DTLS isn't an option here.

> I guess it depends on your definition of roll your own. We didn't invent AES-GCM or implement it. We are using the implementation shipped with the Golang stdlib.

You need to read better. I didn't say "crypto primitives", I've said "crypto _system_". That includes everything, including primitives, key management, authentication, replay (which means your application protocol is now part of the crypto system, not a good sign), field concatenation for singing/hashing, &c.

The most important thing is that when your improvised system fails, you will more-than-likely never know and it'll never cause any errors.