LKML 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 ` (3 more replies) 0 siblings, 4 replies; 7+ 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 ^ permalink raw reply [flat|nested] 7+ 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 ` (2 subsequent siblings) 3 siblings, 0 replies; 7+ 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 ^ permalink raw reply [flat|nested] 7+ 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; 7+ messages in thread From: Jason A. Donenfeld @ 2019-09-25 10:14 UTC (permalink / raw) To: David Miller; +Cc: WireGuard mailing list, Netdev, LKML 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 ^ permalink raw reply [flat|nested] 7+ 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 ` (2 preceding siblings ...) 2019-09-25 9:39 ` David Miller @ 2019-09-29 18:31 ` David Sterba 3 siblings, 0 replies; 7+ messages in thread From: David Sterba @ 2019-09-29 18:31 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list, Netdev, LKML Hi, On Wed, Sep 25, 2019 at 10:29:45AM +0200, Jason A. Donenfeld wrote: > 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. I have some WIP code to port WG to the crypto API, more to get an idea how hard it would be, though I read you've ported it to the api already. My other project (btrfs) is going to use blake2 in kernel and for that I'm about to submit the code, that's where it's also of interest for wg. My work is at 'github.com/kdave/WireGuard branch lkca-1'. I tried to find a way how to minimize the impact on current wg code but make it possible to iteratively extend it to the crypto API. So, there's some config-time ifdefery to select which crypto functions are using kernel or zinc api. See wg.git/src/crypto/Kbuild.include at the top, plus some source ifdefs. I made an example of blake2s port, but only compile tested. There are several problems in general that need to be solved on the kernel side first, before wireguard can work inside the kernel code base: * missing crypto functions in kernel * blake2 * curve25519 (missing completely) * missing generic crypto API callback to use blake_init_key, it's possible to use only the no-key variant (I have a patch for that, it's really easy but it's change in API so ...) The known problem is the cumbersome way to use the crypto functions, eg. for chacha/poly, I understand the pain and perhaps the reasons to start a fresh crypto library. I'm afraid the first implementation with current state of crypto API will be slow, until the API is extended to provide simple ways to transform buffers without scatterlists, request allocations, locking tfm context and whatnot. Feel free to reuse anything from the code if you think it's going the right direction. I'm not sure if I'll have time to continue with the port but at least you can consider blake2 on the way upstream. d. ^ permalink raw reply [flat|nested] 7+ messages in thread

LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git