On Wed, Jul 12, 2017 at 5:39 PM, Wes Young <[email protected]> wrote: > [thinking out-loud here, seeing if anyone is thinking about this] > > tl;dr: has anyone messed with “overloading” beacon or gossip generally > speaking? (curve or o/w). > > i’m mapping curve down through zyre [and gossip] (using ZAP, etc), i’ve got a > prototype working but thinking about trivial ways to enable basic public key > exchange (forcing some of that up to ZAP where possible). starting with some > trivial stuff, and working up towards the more complex issues (verification, > key signing, etc). > > i’m messing with the idea of modifying zbeacon packets to broadcast a peer’s > public key along with their uuid, which seems to work OK, but prob requires a > new ver of beacon RFC. > > i rlz it may not make sense to enable crypto on a local lan where beacon > works, but with the idea of zyre being “zeroconf” and helping people get > their feet wet with zyre+curve, it presents an interesting use case for > zyre+curve and getting folks to the next step w/o having to really get into > the nitty details of authenticated keys first. > > cheap, auto-negociated TLS at the expense of “breaking" current beacon RFC > (although i can prob find a way around this since beacon is supposed to > disregard ‘bad’ packets anyway?) also, spending some thought on how to map > this to gossip (might need to overload endpoint PUBLISH or modify gossip_msg > to signal keys where they exist). > > judging by older threads, most people focused on the “central directory” > model around making sure keys are “verified”, which is where i think you want > to get. however i also think there’s something to be said for enabling > semi-verified TLS where you can as you think through the problem (eg: using > self-signed certs while you figure out how signed cert process fits into your > app). curious if others are/have ventured down this path with zyre…
We discussed adding encryption support to Zyre at last fosdem zeromq hackaton, where we were using the glard daemon. I think the simplest use case would be to distribute keys in a "wifi pre-shared-key way", like a shared password to decrypt a specific zyre channel. I think in the glard case the channel was hardcoded to a specific value. The idea with encrypted zyre was that your fridge could discover your TV, and if the manufacturer would have set the crypto keys in advance, both devices could talk to each other in an encrypted way. Just my 2 cents, -- Benjamin Henrion <bhenrion at ffii.org> FFII Brussels - +32-484-566109 - +32-2-3500762 "In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators." _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
