Trying latest jitsi nightly 2.9.5511-1_amd64 on ubuntu 15.10 and I have
noticed that Jitsi calls fail when I force AES256 in a ZRTP call
(net.java.sip.communicator.gnu.java.zrtp.ZrtpConstants_SupportedSymCiphers=AES3;AES1;)

The INVITE seems to be answered OK and ZRTP is negotiated and the SAS
checks out, but there's no audio and after 30 seconds the call hangs up.

Jitsi logs show:

2016-05-06 21:33:26.899 SEVERE: [550]
org.jitsi.impl.neomedia.RTPConnectorOutputStream.error() Failed to handle
an outgoing packet:
java.lang.IllegalArgumentException: key.length != BLKLEN
at
org.jitsi.impl.neomedia.transform.srtp.SRTPCipherCTROpenSSL.init(SRTPCipherCTROpenSSL.java:63)
at
org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.deriveSrtpKeys(SRTPCryptoContext.java:396)
at
org.jitsi.impl.neomedia.transform.srtp.SRTPTransformer.getContext(SRTPTransformer.java:168)
at
org.jitsi.impl.neomedia.transform.srtp.SRTPTransformer.transform(SRTPTransformer.java:214)
at
org.jitsi.impl.neomedia.transform.zrtp.ZRTPTransformEngine.transform(ZRTPTransformEngine.java:735)
at
org.jitsi.impl.neomedia.transform.SinglePacketTransformer.transform(SinglePacketTransformer.java:192)
at
org.jitsi.impl.neomedia.transform.TransformEngineChain$PacketTransformerChain.transform(TransformEngineChain.java:358)
at
org.jitsi.impl.neomedia.transform.TransformEngineChain$PacketTransformerChain.transform(TransformEngineChain.java:314)
at
org.jitsi.impl.neomedia.transform.AbstractTransformOutputStream.transform(AbstractTransformOutputStream.java:70)
at
org.jitsi.impl.neomedia.transform.TransformOutputStreamImpl.transform(TransformOutputStreamImpl.java:101)
at
org.jitsi.impl.neomedia.transform.TransformUDPOutputStream.packetize(TransformUDPOutputStream.java:79)
at
org.jitsi.impl.neomedia.RTPConnectorOutputStream$Queue.runInSendThread(RTPConnectorOutputStream.java:918)
at
org.jitsi.impl.neomedia.RTPConnectorOutputStream$Queue.access$300(RTPConnectorOutputStream.java:724)
at
org.jitsi.impl.neomedia.RTPConnectorOutputStream$Queue$1.run(RTPConnectorOutputStream.java:796)

It seems to me there's a problem with the implementation of AES256. IIRC,
Jitsi used to work fine with AES256 some time ago, so I assume this was
some recent change that broke things?

It seems to me there's a problem with the implementation of AES256. IIRC,
Jitsi used to work fine with AES256 some time ago, so I assume this was some
recent change that broke things?

Yes, there were some changes in libjitsi for the Jitsi Videobridge to improve the performance by using OpenSSL's implementation of AES. Apparently something goes wrong when AES256 is used and not "normal" AES.

@Etienne, please take a look.

Is this a legit bug? Any way I can further help debug?

Yes, on Linux. Not really, thanks for the report. It should be possible to work around it by deleting libjnopenssl.so. Not sure right now, but it probably is embedded in libjitsi.jar.

>
> > It seems to me there's a problem with the implementation of AES256.
IIRC,
> > Jitsi used to work fine with AES256 some time ago, so I assume this
was some
> > recent change that broke things?
>
> Yes, there were some changes in libjitsi for the Jitsi Videobridge to
improve the performance by using OpenSSL's implementation of AES.
Apparently something goes wrong when AES256 is used and not "normal" AES.
>
> @Etienne, please take a look.

I will try next week.

>
> > Is this a legit bug? Any way I can further help debug?
>
> Yes, on Linux. Not really, thanks for the report. It should be possible
to work around it by deleting libjnopenssl.so. Not sure right now, but it
probably is embedded in libjitsi.jar.

I've just reread the code and i think it never worked and just silently
used AES128.
AES256 use a block size of 128 bits (same as AES128) but with a key size of
256 bits instead of 128bits.

This seems broken since the introduction of multiple AES implementations. Unfortunately, the commit above is rather useless to inspect because of the stupid reformatting while changing code at the same time. But anyway this needs to be fixed. Would you be able to do that Etienne?

If the native code doesn't support AES256 because of some hardcoded stuff, an automatic fallback to plain Java AES would IMO be fine.

Le 7 mai 2016 01:30, "Ingo Bauersachs" <ingo@jitsi.org > <mailto:ingo@jitsi.org> > a écrit :
>
> > It seems to me there's a problem with the implementation of
AES256. IIRC,
> > Jitsi used to work fine with AES256 some time ago, so I
assume this was some
> > recent change that broke things?
>
> Yes, there were some changes in libjitsi for the Jitsi
Videobridge to improve the performance by using OpenSSL's
implementation of AES. Apparently something goes wrong when AES256 is
used and not "normal" AES.
>
> @Etienne, please take a look.

I will try next week.

>
> > Is this a legit bug? Any way I can further help debug?
>
> Yes, on Linux. Not really, thanks for the report. It should
be possible to work around it by deleting libjnopenssl.so. Not sure
right now, but it probably is embedded in libjitsi.jar.

I've just reread the code and i think it never worked and just
silently used AES128.

AES256 use a block size of 128 bits (same as AES128) but with a key
size of 256 bits instead of 128bits.

To be honest I don't really recall if I was ever able to make AES256 calls
to other clients.
I would guess that probably not given what you wrote. Most likely I thought
AES256 was being used when in reality it was falling back to AES128. I do
remember (last year?) forcing AES256 in sip.communicator.properties and not
having the same errors we see now, but it's been too long for me to really
remember the details.

Anyway, I understand it's not a priority for you and the jury is still out
whether AES256 is worth the extra penalty or not (I've seen convincing
arguments for both sides).

I'm doing some thorough testing regarding compatibility between jitsi and
linphone and I'll keep the list updated if I see anything else.

Le 7 mai 2016 01:30, "Ingo Bauersachs" <ingo@jitsi.org> a écrit :
>
> > It seems to me there's a problem with the implementation of AES256.
IIRC,
> > Jitsi used to work fine with AES256 some time ago, so I assume this
was some
> > recent change that broke things?
>
> Yes, there were some changes in libjitsi for the Jitsi Videobridge to
improve the performance by using OpenSSL's implementation of AES.
Apparently something goes wrong when AES256 is used and not "normal" AES.
>
> @Etienne, please take a look.

I will try next week.

>
> > Is this a legit bug? Any way I can further help debug?
>
> Yes, on Linux. Not really, thanks for the report. It should be possible
to work around it by deleting libjnopenssl.so. Not sure right now, but it
probably is embedded in libjitsi.jar.

I've just reread the code and i think it never worked and just silently
used AES128.
AES256 use a block size of 128 bits (same as AES128) but with a key size
of 256 bits instead of 128bits.

If you take a look at AES.java before my modifications, you have 4 AES
implementations, and all 4 are AES128:

This seems broken since the introduction of multiple AES implementations.
Unfortunately, the commit above is rather useless to inspect because of the
stupid reformatting while changing code at the same time. But anyway this
needs to be fixed. Would you be able to do that Etienne?

If the native code doesn't support AES256 because of some hardcoded stuff,
an automatic fallback to plain Java AES would IMO be fine.

And for new applications I suggest that people don't use AES-256. AES-128
provides more than enough security margin for the forseeable future. But if
you're already using AES-256, there's no reason to change.

Also i will definitly not work on AES256 while ZrtpFortuna is still used.

I would guess that probably not given what you wrote. Most likely I thought
AES256 was being used when in reality it was falling back to AES128. I do
remember (last year?) forcing AES256 in sip.communicator.properties and not
having the same errors we see now, but it's been too long for me to really
remember the details.

Anyway, I understand it's not a priority for you and the jury is still out
whether AES256 is worth the extra penalty or not (I've seen convincing
arguments for both sides).

I'm doing some thorough testing regarding compatibility between jitsi and
linphone and I'll keep the list updated if I see anything else.