tinc - Apr 2014 - BF_encrypt & BF_decrypt when using AES ?

Hi,

I'm doing some perf profiling, and I can see that BF_encrypt &
BF_decrypt of libcrypto.so.1.0.0 (used in tincd) are consuming CPU time.

I'm using Tinc 1.0.23 and Cipher = aes-128-cbc

BF_encrypt & BF_decrypt seems related to Blowfish
(https://www.openssl.org/docs/crypto/blowfish.html).

Is it normal that BF functions are used even if AES is used ? I do not
know anything about it so I'm just asking :)

I have configured "Cipher = aes-128-cbc" only on the node that has
"ConnecTo", is this the right way to do or does it have to be both
side
? (example : node1 is configured without ConnecTo, and only have node2
public key in config, but node2 has ConnectTo and Cipher for node1)

Thank you ;)

On Fri, Apr 11, 2014 at 02:00:57PM +0200, Florent B wrote:
> I'm doing some perf profiling, and I can see that BF_encrypt &
> BF_decrypt of libcrypto.so.1.0.0 (used in tincd) are consuming CPU time.
> 
> I'm using Tinc 1.0.23 and Cipher = aes-128-cbc
> 
> BF_encrypt & BF_decrypt seems related to Blowfish
> (https://www.openssl.org/docs/crypto/blowfish.html).
> 
> Is it normal that BF functions are used even if AES is used ? I do not
> know anything about it so I'm just asking :)
Yes. When you set Cipher = aes-128-cbc, then AES will be used for the
encryption of UDP packets. However, in tinc 1.0.x, the meta-connections always
use bf-cbc as the cipher.
> I have configured "Cipher = aes-128-cbc" only on the node that
has
> "ConnecTo", is this the right way to do or does it have to be
both side
> ? (example : node1 is configured without ConnecTo, and only have node2
> public key in config, but node2 has ConnectTo and Cipher for node1)
You should have it on both sides.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20140411/f59c1ad8/attachment.sig>