Re: [Openvpn-devel] [PATCH] Use RSA_generate_key_ex() instead of deprecated, RSA_generate_key()

[Gert Doering]

Hi,

On Mon, Dec 30, 2013 at 12:25:55AM +0100, Steffan Karger wrote:
> I've given the stripping out a little more thought and think I'm in
> favour of stripping this out of 2.4, but keep support in 2.3 to not
> break anything for minor releases. Removing this cipher mode sounds
> like a feature to me ;)

Thanks for your explanation.  Yes, this sounds good to me.

As Arne also ACKed the patch, I'll merge it into 2.3 only ("soonish").

Could I ask you to provide a patch to remove this for 2.4?

thanks,

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpKHIBERqvgv.pgp
Description: PGP signature

Re: [Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[Heikki Hannikainen]

On Mon, Dec 23, 2013 at 4:43 PM, André Valentin  wrote:
> On 23.12.2013 12:32, Gert Doering wrote:
>> We've discussed the patch on the Munich Hackathon, and we intend to do
>> it in a different way.  James wants to change the packet format for
>> data packets anyway (due to bad alignment in the current packet format),
>> and the new format would have the option to send the session ID in the
>> data packet as well, like "normally it's not sent, but if we have't heard
>> from the server longer than  time units, send a session ID so that
>> hmac-float will work".
>
> Of course, this is a better idea and should have less problems with scaling.
> But there should be an option for the client to always send the session id,
> so that there are no timeouts if the user decides to do so.

+1 to that - it'd be really neat if floating would work seamlessly
without timeouts + retransmissions. It'd be very useful on mobile
devices, which often get hit by NAT timeouts on UDP (around 30 or 60
seconds typically), switches between WIFI and 3G, and keepalive pings
with tight timers (sub-30-second range) consume a lot of battery.

The regular SSL session ID is maybe a bit long to be sent with each
and every packet, though.

Which other enhancements to the packet format are necessary? I
gathered that the encrypted data needs to be aligned for AES-NI to
work, which probably means that either the packet headers need to be
padded so that the data starts on a nice word boundary, or that the
data packet needs to begin with the encrypted data and all the headers
need to be placed in the end of the packet. Right?

And then some backwards compatibility in the handshake - it'd be good
if old clients could optionally be allowed on new servers using the
new packet format.

>> This code has not been written yet, though, and we have no specific
>> timelines when it will happen.
> So what does this mean for my work and the current format? Is there still
> a possibility that it will be integrated for the 'old packet format'?

We could also start working on the new packet format, do a prototype
if you'd like. Just need to figure out what the exact requirements
would be.

 - Hessu