[Openvpn-devel] [PATCH 1/7] refine assertion to allow other modes than CBC

cipher_ctx_final() only returns an outlen in CBC mode. If CFB or OFB are used the assertion outlen == iv_len is always false. There's no CBC mode defined for the GOST 28147-89 block cipher. Hence this patch is needed for it to work. It's needed for other ciphers like BF-CFB as well, though.

[Openvpn-devel] [PATCH 2/7] init crypto engine before SSL library

Since GOST in OpenSSL is implemented in an engine, the engine must be loaded before the SSL library is initialized for the algorithms to become available for SSL/TLS. This delays the initialization of the ssl lib until after the options are parsed, so a possibly configured engine can be loaded

[Openvpn-devel] [PATCH 3/7] remove API for crypto engine initialization

Since the crypto library and the crypto engine initialization are now happening at the same time, there's no apparent need for two distinct APIs the init them anymore. The crypto engine is now initialized within the crypto library init function, which makes to code look a bit cleaner.

[Openvpn-devel] [PATCH 4/7] support crypto engine options

OpenVPN supports using OpenSSL engines by loading them with the --engine configuration option. Some of those engines require configuration options themself. This patch extends the --engine option so that engine-options can be specified as well. Signed-off-by: Heiko Hund

[Openvpn-devel] [PATCH 6/7] do MACs using EVP_MD_CTX with openssl >= 1.0.0

Using EVP_MD_CTX for MAC calculation allows to use other algorithms than HMAC. In this particular case it allows the GOST-MAC to be used. GOST-MAC uses a 256 bit key and produces a 32 bit signature. Unfortunately OpenSSL has no API for querying a MAC's key length, so the key length is returned

[Openvpn-devel] [PATCH 7/7] change HMAC to MAC where applicable

Sine there's --auth gost-mac, using HMAC throughout the code is misleading. Especially in the crypto code itself. This changes function and variable names as well as comments to use the more generic MAC instead. Signed-off-by: Heiko Hund --- doc/openvpn.8

Re: [Openvpn-devel] RFC: tun/tap cleanup at program end

On Aug 15, 2012, at 05:53:40, Gert Doering wrote: > Hi, > > On Wed, Aug 15, 2012 at 12:00:12PM +0200, Gert Doering wrote: >> 3 - check for the existance of "--dev tap3" and remember, not cleaning >> if it existed previously, doing this with RT_NETLINK which should >>

[Openvpn-devel] [PATCH] Keep pre-existing tun/tap devices around on *BSD

This amends commit 62c613d46dc49 to check whether a named tun/tap device ("--dev tunX" instead of "--dev tun") exists before OpenVPN started - if yes, keep around at program end. If no, destroy. Also has a spelling fix, and changes clear_tuntap() to be "static" (only ever called from within

[Openvpn-devel] housekeeping patches for 2.3

Hi, as discussed on IRC, the "--version" output for IPv6 is no longer useful in its existing form -> shorten (but keep, to point out "yes, this has IPv6" even if *we* all know). Add another convenience patch to t_client.sh, to put the command line used by a specific test run into the

[Openvpn-devel] [PATCH 1/2] Put actual OpenVPN command line on top of corresponding log file.

This is useful if a test fails, and the tester wants to run the very same OpenVPN call with the very same arguments interactively to pinpoint and fix the problem. Signed-off-by: Gert Doering --- tests/t_client.sh.in |3 ++- 1 files changed, 2 insertions(+), 1

[Openvpn-devel] [PATCH 2/2] Reduce --version string detail about IPv6 to just "[IPv6]".

For 2.3 release, we do not need to have more details, as there is no separate patch set anymore, and both IPv6 transport and IPv6 payload (PF_INET6) have been fully integrated. Signed-off-by: Gert Doering --- src/openvpn/options.c |3 +-- 1 files changed, 1