[Combining threads.]
The work on the OpenSSL fork, and figuring out just what the right interface is
to bring PQ crypto to current crypto libraries, is going to be on-going. PQ
crypto algorithms don’t fit so well in the common conventions we’ve become
accustomed to for current algorithms.
As for the dialer, I need to look into getting approval to upstream it, but I
expect I can share it. The goal of that work was to have some real basic
integration with the network connections flyout that appears when you click its
icon in the notification area. What I’ve done is modest, though, so let me make
clear what I’ve actually done. I changed OpenVPN-GUI when it starts up to
create such an entry for each configuration file it finds, and if the user
clicks “Connect” on one of those entries, it’s exactly the same as if the user
brought up the right-click menu for OpenVPN-GUI’s icon, selected that
configuration file, and clicked Connect. The plug-in sends the exact same
Windows message to OpenVPN-GUI, which causes it to bring up its status window
and instruct the system service to establish the connection. That’s it.
So there are some caveats. 1) OpenVPN-GUI has to be running; the plug-in will
complain if it’s not. In fact OpenVPN-GUI clears out the list when it exits
cleanly. 2) If OpenVPN-GUI crashes, the entries will be left in the list but
won’t be usable for anything. I prefix each entry with the string “OpenVPN “,
though, and the next time it runs it will clean up these entries. 3) Because
OpenVPN uses tap-windows instead of the normal Windows NDIS devices for the
networking, the flyout can’t detect whether or not the connection is active or
not, and so it will always present a “Connect” button. OpenVPN-GUI ignores this
when the connection is already alive, so nothing bad happens, but it can be a
confusing experience. I didn’t investigate what it might take to get
tap-windows to surface its connected/disconnected state to the flyout in the
correct way, nor did I investigate if this could be used to automatically bring
up connections on demand or before login.
That all being said, the dialer plugin itself could be expanded to do directly
what I’m currently offloading onto a running OpenVPN-GUI process, communicating
with the system service directly and removing the need for OpenVPN-GUI to be
running. It just means replicating that functionality in the plugin itself.
This is one obvious blocker to using it before login, since the GUI process
wouldn’t be running before login. If it’s possible to trigger this before
login, code running before login runs in a privileged system context, and so
the usual warnings about the dangers of privileged code apply.
I’ll look into getting clearance, and assuming there are no problems, I’ll get
a patch together for you all to look at.
-----Original Message-----
From: Gert Doering <g...@greenie.muc.de>
Sent: Wednesday, July 4, 2018 8:11 AM
To: Kevin Kane <kk...@microsoft.com>
Cc: Jon Kunkee <jkun...@microsoft.com>; Samuli Seppänen <sam...@openvpn.net>;
???????? ?????????????? <chipits...@gmail.com>; openvpn-devel
<openvpn-devel@lists.sourceforge.net>
Subject: Re: [Openvpn-devel] Upstreaming pqcrypto changes from microsoft/openvpn
Hi Kevin,
besides the PQ Crypto stuff (which I find less interesting than Steffan,
because I'm the packet geek and he's the Man Who Understands Crypto :-) ), you
also have done "something with an openvpndial-0.1.dll".
Wild guessing suggests that this is hooking into the Dial-Up-Network control
panel and enabling a new approach to start OpenVPN sessions from DUN, possibly
even "on demand" or "before login".
Is this work you can (and want to) share?
gert
--
"If was one thing all people took for granted, was conviction that if you feed
honest figures into a computer, honest figures come out. Never doubted it
myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany
g...@greenie.muc.de<mailto:g...@greenie.muc.de>
From: Илья Шипицин <chipits...@gmail.com>
Sent: Wednesday, July 4, 2018 1:04 AM
To: Kevin Kane <kk...@microsoft.com>
Cc: Jon Kunkee <jkun...@microsoft.com>; Samuli Seppänen <sam...@openvpn.net>;
openvpn-devel <openvpn-devel@lists.sourceforge.net>
Subject: Re: Upstreaming pqcrypto changes from microsoft/openvpn
Hi,
I meant "vpndialer" part first :)
as for PQ crypto - I played with it, however, it is currently far from
worldwide adoption (if that would have been implemented as openssl loadable
engine, it would be more luck....)
ср, 4 июл. 2018 г. в 5:17, Kevin Kane
<kk...@microsoft.com<mailto:kk...@microsoft.com>>:
Hello all,
Thanks to Jon for making the introduction. My team works on post-quantum (PQ)
cryptography, which is algorithms used by regular computers but which are
resistant to attack by a sufficiently powerful quantum computer. This OpenVPN
fork is an example application we released so the public could experiment with
it.
The following sites have information on what we're doing:
Our openvpn, openvpn-build, and openvpn-gui forks are subprojects of the
following repo:
https://github.com/Microsoft/PQCrypto-VPN<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FPQCrypto-VPN&data=02%7C01%7Ckkane%40microsoft.com%7C5a6cdd9d83284f43032008d5e184c7bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662882760509165&sdata=WjzDZ7YtQ8WcrC%2BQbiD%2BXbfO9qW8LEsDCSbkgSMvJkc%3D&reserved=0>
I just realized there are no back-pointers from the subprojects back to the
main repo. I've just corrected that.
On this site are scripts and instructions for doing our custom build of OpenVPN
for Windows and Linux, to use the PQ crypto-enabled fork of OpenSSL we use, and
how to properly configure it for PQ crypto. We also provide instructions for
building an image for a Raspberry Pi to be used as a wifi access point that
tunnels all traffic to a remote server protected by PQ key exchange. We also
have released pre-built Linux x64 and Windows binaries. Our current build
process works but there is plenty of room for improvement.
A more in-depth description of the PQ VPN is here:
https://www.microsoft.com/en-us/research/project/post-quantum-crypto-vpn/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fproject%2Fpost-quantum-crypto-vpn%2F&data=02%7C01%7Ckkane%40microsoft.com%7C5a6cdd9d83284f43032008d5e184c7bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662882760519179&sdata=SjAqeik0aRmiWupi%2F2FAGVk9Ejwy%2B2WZ3y1O7ARUNm0%3D&reserved=0>
And our introduction to post-quantum cryptography overall is here:
https://www.microsoft.com/en-us/research/project/post-quantum-cryptography/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fproject%2Fpost-quantum-cryptography%2F&data=02%7C01%7Ckkane%40microsoft.com%7C5a6cdd9d83284f43032008d5e184c7bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662882760519179&sdata=TqvD%2B34%2BN%2FN%2Fl0j71ZO%2B06F3SR6atmfe0Tg2n6aaKeE%3D&reserved=0>
As Jon said, these algorithms are experimental and so it would be inappropriate
to introduce them into production code until the standardization and thorough
analysis by the cryptographic community are completed. When that happens, we
want to be ready to quickly integrate these algorithms into existing software.
My colleagues are already contributing to a PQ crypto-enabled fork of OpenSSL
(https://github.com/open-quantum-safe/openssl<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopen-quantum-safe%2Fopenssl&data=02%7C01%7Ckkane%40microsoft.com%7C5a6cdd9d83284f43032008d5e184c7bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662882760529180&sdata=xDkmtp6OtnQiKcibGtHgbEri14ReESiOIRC9QZMO%2Bbk%3D&reserved=0>),
and similarly we believe there is value in maintaining a PQ-enabled fork of
OpenVPN, so that both are ready when there is consensus on a standard.
I will be updating the fork to track the forward progress of both the
PQ-enabled OpenSSL fork and OpenVPN as time allows, but I welcome the
participation of anyone who's interested in helping with the updates or making
other improvements, as well as any suggestions you may have on future
directions for this work.
-----Original Message-----
From: Jon Kunkee
Sent: Tuesday, July 3, 2018 4:20 PM
To: Samuli Seppänen <sam...@openvpn.net<mailto:sam...@openvpn.net>>; Илья
Шипицин <chipits...@gmail.com<mailto:chipits...@gmail.com>>; Kevin Kane
<kk...@microsoft.com<mailto:kk...@microsoft.com>>
Cc: openvpn-devel
<openvpn-devel@lists.sourceforge.net<mailto:openvpn-devel@lists.sourceforge.net>>
Subject: Upstreaming pqcrypto changes from microsoft/openvpn
Hi,
(Retitling thread from RE: [Openvpn-devel] Topics for the community meeting
(Wed, 13th June 2018))
> do you know this activity
> https://github.com/Microsoft/openvpn/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fopenvpn%2F&data=02%7C01%7Ckkane%40microsoft.com%7C5a6cdd9d83284f43032008d5e184c7bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662882760529180&sdata=huHNbNBIsD%2BaX%2F%2BIH5BdFlRrWBrivVi3zGhwY1hmR%2BU%3D&reserved=0>
> ?
> there are interesting things
There are *very* interesting things there!
> Do you know if Kevin (or his manager/team) plans to push his work upstream
> (i.e. to us) at some point?
Samuli and Илья, I'd like to introduce you to Kevin Kane. He is the current
maintainer of the Microsoft\openvpn pqcrypto branch on Github.
He is working on developing encryption standards that are resistant to
quantum-mechanics-based attacks. This includes taking existing products and
adding experimental implementations of the experimental standards to
them—including OpenVPN and OpenSSL. Over time these new techniques will be
studied, refined, tested, and otherwise hammered on in the furnace of
open-source cryptography until they gain some measure of trust.
Both the experimental and untested nature of his work mean that no, his code
isn’t ready to be merged into OpenVPN/master…yet!
In the meantime, he would love to work with someone from the OpenVPN
community—or even the organization itself—to make the connection official and
to refine his additions. Some of the needed refinement requires familiarity
with the overall build system, while a forward-looking cryptographer or
protocol guru might take interest in what's developing under the hood.
I don't know much about the current status of the project, but Kevin is happy
to answer questions and would love to hear from you.
Thanks,
Jon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
