Hello David & @all
Thanks for the answers, I think I have now understood a lot better than before ... especially the purpose of sharing on 2
channels. But it's really hard to process that all in mind. I will try to describe the basics from a very high viewpoint, what I
have understand, without details.
The control channel is not DTLS for UDP/IP, but is functionally similar as DTLS. RSA encrypts traffic on the control channel
with an asymmetric key. --tls-auth improves security with HMAC.
The data channel is encrypted with a symmetric key, regardless from the control-channel, ideally with an ephemeral key and e.g.
AES. --auth also improves security with HMAC.
The symmetric key always has the correct length and strenght regardless of the 'depth' of the RSA key. With a 'smaller' RSA
depth, only the symmetric-key-negotiation is weaker.
That's how I understood it now. And I hope I can ask one more question about this process. At the point I still lack the
understanding for the key negotiation with DH.
If I understand that correctly, DH does not encrypt additionally during the negotiation, it use the RSA encrypted control
channel. Either a static dh.pem file or an 'elliptical curve' is used in this negotiation ... but both are just the base of the
public key, which it can be transmitted uncertainly ... both are just a very large prime number. Is it here the same as in RSA,
that a smaller bit value only leads to a smaller prime, which only leads to a weaker entropy in the key negotiation ...? ... but
there is also no necessarily negative effect on the strength or the size of the negotiated one symmetrical key?
If what I have described here is interpreted correctly, then in my opinion the best breaking point in an attack to break the
encryption would be a too low RSA value. But even if RSA-2048 is not recommended for long-term storage for later than the year
2030, it still means that today's short-lived OpenVPN-Session based on RSA-2048->Control-Channel can not be breaked today. And
if the Hack of a recorded session is continued to or after 2030, it can not be breaked retroactively, because it is not
possible to reconstruct the ephemeral symmetric key ... even if the complete packet traffic was recorded .... that does not work
because the peers' secret key is not available and not recoverable. Is this conclusion correct?
Do not worry, I'm not paranoid ... ;-) ... I just try to understand the matter better and then make better own decisions.
Wishful thinking about how something possibly has to be or can be is never a good base for making decisions.
Best Regards
Tom
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
