Fwknop fails if GnuPG key size is 4096 bits long

[rennhak]

Abstract

Fwknop client / libfko fails when GPG key size length is 4096 bits.

Description

Fwknop client allows usage via GPG encryption with HMAC, which is very convenient and secure.

We use this via eg.

fwknop -A 'tcp/$PORT' --gpg-recip $SERVER_KEYID --gpg-sign $CLIENT_KEYID -R -D $SERVERIP -v -U $NAME --resolve-url 'http://whatismyip.akamai.com/' --key-base64-hmac '$HMAC'

If the GPG key used is eg. RSA/RSA 2048 then this works flawlessly. Unfortuantely, when key used it RSA/RSA 4096 then it fails.

fwknop: fko_spa_data_final: Error 57 - Args contain invalid data: FKO_ERROR_INVALID_DATA_ENCRYPT_GPG_RESULT_MSGLEN_VALIDFAIL

Even with highest possible compression with GPG this seems to fail. I suspect that the packet size exceeds allowed maximum Ethernet frame size.

It is debatable if RSA 4096 keys are really needed compared to 2048 bits, but it might be worth marking as a bug as other users with keys like that might fall onto this same problem.

Probably a simple change to fail early with message like 'GPG key size too large, 4096 bits is not supported' will massively improve UX.

Synopsis

• Patch FWKnop / Libfko to fail early if GPG key length used exceeds allowed limit

Reference

$  fwknop --version
fwknop client 2.6.8, FKO protocol version 2.0.2

$ gpg --version
gpg (GnuPG) 2.0.28
libgcrypt 1.6.5

    Digest Type: 3 (SHA256)
      HMAC Type: 3 (SHA256)
Encryption Type: 2 (GPG)
Encryption Mode: 7 (Asymmetric)

Related

• Re-opened as new (this ticket), since #136 is closed.

[mrash]

Yes, indeed, 4096-bit keys send the payload data size beyond the Ethernet MTU. There are a few possibilities to try and work around this, but none are really supported yet:

• In the UDP server mode where pcap is not used at all, then it should be easier to send the entire payload over the UDP socket even though this would still not be a single Ethernet frame. This is also possible in pcap mode too, but more code would have to be added to emulate what we should get via the UDP socket for free.
• We are considering a binary SPA packet format along with not requiring base64 encoding, so if we actually implement this (it would take a while, and would not be backwards compatible), we might decrease the SPA data size below the Ethernet MTU even for 4096-bit keys. I haven't done any real testing, so this is just a guess.
• On 10Gb networks with jumbo frames, this problem should go away to some extent, but likely only for local communications I think so this is of limited value.

[itoffshore]

I've been encrypting with 4096 bit RSA keys for a little while now.

• Using an ed25519 key as the signing key on 4096 bit RSA keys works without any problems - see below https://github.com/mrash/fwknop/issues/211#issuecomment-757257432

[rennhak]

@itoffshore Thanks for the workaround, interesting.

[Dreamsorcerer]

To save people trying to find that dead link, it's: gpg2 --expert --full-gen-key Select:

• (11) ECC (set your own capabilities)
• (A) Toggle the authenticate capability
• (Q) Finished
• (1) Curve 25519

[Dreamsorcerer]

Worth also mentioning that using ECC keys for both is not possible (and the error message is totally unhelpful). See https://github.com/mrash/fwknop/issues/323#issuecomment-770269364

It needs to be ECC on client and RSA on server.