similar to: Elliptic curves in tinc

Dear all, ? maybe it is a little early but the next (stable) version of OpenSSL will support Brainpool Ellptic curves (current beta 1.0.2-beta1 contains support for Brainpool already). Brainpool curves are defined in RFC 5639. ? Please find attached a patch file that adds support for Brainpool Elliptic Curves in OpenSSH. Currently, setting the bit size to 256, 384 or 521 selects one of the

Hi there, we're using tinc to mesh together hosts in a public datacenter (instead of using a private VLAN, sort of). So all hosts are reasonably modern; connections are low latency with an available bandwith of around 500Mbit/s or 1Gbit/s (depending on how close they are to each other). Iperf between two nodes directly reports around 940Mbit/s. The CPUs are Intel(R) Core(TM) i7-4770 CPU @

Tinc newbie here so apologies if this is obvious or has been discussed already; I did search but couldn't find anything. I'm testing tinc 1.1pre10 between a Windows 7 client and Linux server. The Linux machine is on the internet and the Windows machine is on my home network behind NAT. I have successfully configured a Linux client on my home network to communicate with the server

Is there any indication of when we might see the protocol stabilize in the 1.1pre branch? It seems to be quite an improvement already. Perhaps some configuration could be added to allow for specifying a protocol version, rather than the 'ExperimentalProtocol=yes' flag? What are the roadblocks to stabilizing it and is there any need or desire for help accomplishing this? While I'm

> On 30 July 2018 at 20:37 ????? <vtol at gmx.net> wrote: > > > > >>>>>>> facing [ no shared cipher ] error with EC private keys. > >>>>>> the client connecting to your instance has to support ecdsa > >>>>>> > >>>>>> > >>>>> It does - Thunderbird 60.0b10 (64-bit) >

Hi all, I'm back again with my speed issues. The past issues where dependant of network I used. Now I run my tests in a lab, with 2 configurations linked by a Gigabit switch : node1: Intel Core i5-2400 with Debian 7.2 node2: Intel Core i5-3570 with Debian 7.2 Both have AES and PCLMULQDQ announced in /proc/cpuinfo. I use Tinc 1.1 from Git. When I run an iperf test from node2 (client) to

I've been using SPTPS (a.k.a ExperimentalProtocol) for a while now, but I've only recently started looking into the details of the protocol itself. I have some questions about the design: - I am not sure what the thread model for SPTPS is when compared with the legacy protocol. SPTPS is vastly more complex than the legacy protocol (it adds a whole new handshake mechanism), and

Hi, I'm currently trying to troubleshoot what appears to be a very subtle bug (most likely a race condition) in SPTPS that causes state to become corrupted during SPTPS key regeneration. The tinc version currently deployed to my production nodes is git 7ac5263, which is somewhat old (2014-09-06), but I think this is still relevant because the affected code paths haven't really changed

Is SPTPS protocol enabled in 1.1 by default? Or we need to manually enable it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180316/2360e357/attachment.html>

I sent you a pull request that addresses the general issue, at least for the short term: https://github.com/gsliepen/tinc/pull/83 On 16 May 2015 at 19:36, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sat, May 16, 2015 at 04:53:33PM +0100, Etienne Dechamps wrote: > >> I believe there is a design flaw in the way SPTPS key regeneration >> works, because upon reception of

Hi to everybody, Can anybody tell me what packages I need to install Tinc 1.1pre2 in a server that it had installed a previous version installed? I tried to install it and when I execute the "make" it give me a lot of errors. Best regards, Ramses

>>>> I did some local testing and it seems that you are using a curve >>>> that is not acceptable for openssl as a server key. >>>> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem >>>> -port 5555 >>>> using cert generated with brainpool. Everything works if I use >>>> prime256v1 or secp521r1. This is a

Hello, Linux has a recvmmsg() system call which allows to achieve several recvfrom() at a time. The patch below makes tinc use it (patch against 1.1-pre11). Basically the patch turns the handle_incoming_vpn_data variables into arrays (of size 1 when recvmmsg is not available, and thus compiled the same as before), and makes the code index into the arrays. You may want to use interdiff -w

Hi all, I have two nodes, connected to a switch, using Tinc 1.1 from git. They connect each other with sptps, and to other nodes in the Internet with old protocol because they have Tinc 1.0. There is no problem with remote nodes, but between my 2 local nodes, they see 1518 PMTU. But local network is 1500 MTU !!! So nodes can ping each other but larger data does not go. test1=sllm1 test2=sllm2

On 31.07.2018 03:32, ????? wrote: >> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: >> >> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] >> >> And thus t1 would not work anyway. However, having tested r1 the result >> was just the same. >> >> A tcpdump during the openssl test [ s_server | s_client ] then revealed

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> <br> </div> <blockquote type="cite"> <div> On 30 July 2018 at 21:00 ѽ҉ᶬḳ℠ < <a href="mailto:vtol@gmx.net">vtol@gmx.net</a>> wrote: </div> <div> <br>

Hi everybody. I'm struggling with setting up an SPTPS connection between two of my machines. I attached the patch that I used to analyze this. Apparently different keys are derived depending on the crypto backend. Is this intentional? Linking to openssl results in char key[] = { 0xb2, 0x9d, 0x8d, 0x24, 0x91, 0x04, 0xaf, 0x25, 0x3f, 0x10, 0x34, 0x9d, 0xc7, 0x73, 0x8c, 0xe1, 0x24, 0x32,

Hello, I think routing could be improved in several ways, at least, there lacks some documentation describing how Tinc routes packets. In order to test Tinc, I setup the following virtual network: - tinc 1.1pre9 with ExperimentalProtocol=yes - use of network namespaces (actually python-nemu[1]) - star topology, where all nodes runs tinc except the center, which I use to filter communications,

Hello, I'm running a tinc network including dozens of nodes in switch mode. Some are running stable branch 1.0, while a small set of nodes are running 1.1 with ed25519 support. I discovered some routing issue between two nodes: (names are hidden) A (1.1): ConnectTo = B ConnectTo = C IndirectData = yes Mode = Switch B (1.0): Mode = Switch C (1.1 but only with RSA key): Mode = Switch

Hi, I've noticed that Dovecot is using per default the elliptic curve sect571r1. Because not all clients might support sect571r1, I would like to set the elliptic curve manually. Is that possible? -Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/