WireGuard Archive on lore.kernel.org
 help / color / Atom feed
* WireGuard to port to existing Crypto API
@ 2019-09-25  8:29 Jason A. Donenfeld
  2019-09-25  8:46 ` Toke Høiland-Jørgensen
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Jason A. Donenfeld @ 2019-09-25  8:29 UTC (permalink / raw)
  To: WireGuard mailing list, Netdev, LKML

Hi folks,

I'm at the Kernel Recipes conference now and got a chance to talk with
DaveM a bit about WireGuard upstreaming. His viewpoint has recently
solidified: in order to go upstream, WireGuard must port to the
existing crypto API, and handle the Zinc project separately. As DaveM
is the upstream network tree maintainer, his opinion is quite
instructive.

I've long resisted the idea of porting to the existing crypto API,
because I think there are serious problems with it, in terms of
primitives, API, performance, and overall safety. I didn't want to
ship WireGuard in a form that I thought was sub-optimal from a
security perspective, since WireGuard is a security-focused project.

But it seems like with or without us, WireGuard will get ported to the
existing crypto API. So it's probably better that we just fully
embrace it, and afterwards work evolutionarily to get Zinc into Linux
piecemeal. I've ported WireGuard already several times as a PoC to the
API and have a decent idea of the ways it can go wrong and generally
how to do it in the least-bad way.

I realize this kind of compromise might come as a disappointment for
some folks. But it's probably better that as a project we remain
intimately involved with our Linux kernel users and the security of
the implementation, rather than slinking away in protest because we
couldn't get it all in at once. So we'll work with upstream, port to
the crypto API, and get the process moving again. We'll pick up the
Zinc work after that's done.

I also understand there might be interested folks out there who enjoy
working with the crypto API quite a bit and would be happy to work on
the WireGuard port. Please do get in touch if you'd like to
collaborate.

Jason
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: WireGuard to port to existing Crypto API
  2019-09-25  8:29 WireGuard to port to existing Crypto API Jason A. Donenfeld
@ 2019-09-25  8:46 ` Toke Høiland-Jørgensen
  2019-09-25  9:17 ` Bruno Wolff III
  2019-09-25  9:39 ` David Miller
  2 siblings, 0 replies; 6+ messages in thread
From: Toke Høiland-Jørgensen @ 2019-09-25  8:46 UTC (permalink / raw)
  To: Jason A. Donenfeld, WireGuard mailing list, Netdev, LKML

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> Hi folks,
>
> I'm at the Kernel Recipes conference now and got a chance to talk with
> DaveM a bit about WireGuard upstreaming. His viewpoint has recently
> solidified: in order to go upstream, WireGuard must port to the
> existing crypto API, and handle the Zinc project separately. As DaveM
> is the upstream network tree maintainer, his opinion is quite
> instructive.
>
> I've long resisted the idea of porting to the existing crypto API,
> because I think there are serious problems with it, in terms of
> primitives, API, performance, and overall safety. I didn't want to
> ship WireGuard in a form that I thought was sub-optimal from a
> security perspective, since WireGuard is a security-focused project.
>
> But it seems like with or without us, WireGuard will get ported to the
> existing crypto API. So it's probably better that we just fully
> embrace it, and afterwards work evolutionarily to get Zinc into Linux
> piecemeal. I've ported WireGuard already several times as a PoC to the
> API and have a decent idea of the ways it can go wrong and generally
> how to do it in the least-bad way.
>
> I realize this kind of compromise might come as a disappointment for
> some folks. But it's probably better that as a project we remain
> intimately involved with our Linux kernel users and the security of
> the implementation, rather than slinking away in protest because we
> couldn't get it all in at once. So we'll work with upstream, port to
> the crypto API, and get the process moving again. We'll pick up the
> Zinc work after that's done.

On the contrary, kudos on taking the pragmatic route! Much as I have
enjoyed watching your efforts on Zinc, I always thought it was a shame
it had to hold back the upstreaming of WireGuard. So as far as I'm
concerned, doing that separately sounds like the right approach at this
point, and I'll look forward to seeing the patches land :)

-Toke
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: WireGuard to port to existing Crypto API
  2019-09-25  8:29 WireGuard to port to existing Crypto API Jason A. Donenfeld
  2019-09-25  8:46 ` Toke Høiland-Jørgensen
@ 2019-09-25  9:17 ` Bruno Wolff III
  2019-09-25  9:40   ` David Miller
  2019-09-25  9:39 ` David Miller
  2 siblings, 1 reply; 6+ messages in thread
From: Bruno Wolff III @ 2019-09-25  9:17 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: Netdev, LKML, WireGuard mailing list

Are there going to be two branches, one for using the current API and one 
using Zinc?
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: WireGuard to port to existing Crypto API
  2019-09-25  8:29 WireGuard to port to existing Crypto API Jason A. Donenfeld
  2019-09-25  8:46 ` Toke Høiland-Jørgensen
  2019-09-25  9:17 ` Bruno Wolff III
@ 2019-09-25  9:39 ` David Miller
  2019-09-25 10:14   ` Jason A. Donenfeld
  2 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2019-09-25  9:39 UTC (permalink / raw)
  To: Jason; +Cc: netdev, linux-kernel, wireguard

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Wed, 25 Sep 2019 10:29:45 +0200

> His viewpoint has recently solidified: in order to go upstream,
> WireGuard must port to the existing crypto API, and handle the Zinc
> project separately.

I didn't say "must" anything, I suggested this as a more smoothe
and efficient way forward.

I'm also a bit disappointed that you felt the need to so quickly
make such an explosive posting to the mailing list when we've
just spoken about this amongst ourselves only 20 minutes ago.

Please proceed in a more smoothe and considerate manner for all
parties involved.

Thank you.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: WireGuard to port to existing Crypto API
  2019-09-25  9:17 ` Bruno Wolff III
@ 2019-09-25  9:40   ` David Miller
  0 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2019-09-25  9:40 UTC (permalink / raw)
  To: bruno; +Cc: netdev, linux-kernel, wireguard

From: Bruno Wolff III <bruno@wolff.to>
Date: Wed, 25 Sep 2019 04:17:00 -0500

> Are there going to be two branches, one for using the current API and
> one using Zinc?

This is inapproprate to even discuss at this point.

Let's see what the crypto based stuff looks like, evaluate it,
and then decide how to proceed forward.

Thank you.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: WireGuard to port to existing Crypto API
  2019-09-25  9:39 ` David Miller
@ 2019-09-25 10:14   ` Jason A. Donenfeld
  0 siblings, 0 replies; 6+ messages in thread
From: Jason A. Donenfeld @ 2019-09-25 10:14 UTC (permalink / raw)
  To: David Miller; +Cc: Netdev, LKML, WireGuard mailing list

Hi Dave,

On Wed, Sep 25, 2019 at 12:03 PM David Miller <davem@davemloft.net> wrote:
> I didn't say "must" anything, I suggested this as a more smoothe
> and efficient way forward.

s/must/should/g? However it's characterized, I think your jugements
and opinions are generally sound, and I intend to put them into
action.

> I'm also a bit disappointed that you felt the need to so quickly
> make such an explosive posting to the mailing list when we've

Explosive? That's certainly not the intent here. The project is
changing direction in a big way. Collaborating with others on the
crypto API will be an important part of that. Announcing the change in
direction, those intentions, a rationale on why it will be okay, and
inviting collaboration is a responsible thing to do at the earliest
opportunity. Better to announce intent early rather than surprise
people or deter potential collaborators by keeping plans secret.

Jason
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-25  8:29 WireGuard to port to existing Crypto API Jason A. Donenfeld
2019-09-25  8:46 ` Toke Høiland-Jørgensen
2019-09-25  9:17 ` Bruno Wolff III
2019-09-25  9:40   ` David Miller
2019-09-25  9:39 ` David Miller
2019-09-25 10:14   ` Jason A. Donenfeld

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git