[jitsi-dev] AES256 call fails


#1

Hi all,

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?

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

Cheers,
Peter


#2

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.

Cheers,
Peter

Ingo


#3

> 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.

···

Le 7 mai 2016 01:30, "Ingo Bauersachs" <ingo@jitsi.org> a écrit :

> Cheers,
> Peter

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hi all,

:

>
> > 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:
https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b599ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L644
https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b599ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L663
https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b599ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L680
https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b599ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L769

In my modifications i've added some checks like the one you see/hit
https://github.com/jitsi/libjitsi/blob/9237edaa82fce6208081685b7e0c2955fcfc6625/src/org/jitsi/impl/neomedia/transform/srtp/SRTPCipherCTROpenSSL.java#L63
so instead of silently truncating the 256bits key to 128bits, it now fails

Peter, did you successfully made AES256 call to another client than jitsi?

Regards
Etienne

···

2016-05-07 14:19 GMT+02:00 Etienne Champetier <champetier.etienne@gmail.com>

Le 7 mai 2016 01:30, "Ingo Bauersachs" <ingo@jitsi.org> a écrit :

>
> > Cheers,
> > Peter
>
> Ingo
>


#5

https://github.com/jitsi/libjitsi/commit/e047367699445e05dfc04805afab75f8024e6d79

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.

Ingo

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Etienne
Champetier
Sent: Montag, 9. Mai 2016 10:18
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] AES256 call fails

Hi all,

2016-05-07 14:19 GMT+02:00 Etienne Champetier
<champetier.etienne@gmail.com <mailto:champetier.etienne@gmail.com>
>:

  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.

If you take a look at AES.java before my modifications, you have 4
AES implementations, and all 4 are AES128:
https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b59
9ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L644

https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b59
9ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L663
https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b59
9ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L680
https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b59
9ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L769

In my modifications i've added some checks like the one you see/hit

https://github.com/jitsi/libjitsi/blob/9237edaa82fce6208081685b7e0c29
55fcfc6625/src/org/jitsi/impl/neomedia/transform/srtp/SRTPCipherCTROp
enSSL.java#L63

so instead of silently truncating the 256bits key to 128bits, it now
fails

Peter, did you successfully made AES256 call to another client than
jitsi?

Regards

Etienne

  >
  > > Cheers,
  > > Peter
  >
  > Ingo
  >


#6

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.

Cheers,
Peter

···

On Mon, May 9, 2016 at 9:18 AM, Etienne Champetier < champetier.etienne@gmail.com> wrote:

Hi all,

2016-05-07 14:19 GMT+02:00 Etienne Champetier <
champetier.etienne@gmail.com>:

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:

https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b599ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L644

https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b599ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L663

https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b599ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L680

https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b599ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L769

In my modifications i've added some checks like the one you see/hit

https://github.com/jitsi/libjitsi/blob/9237edaa82fce6208081685b7e0c2955fcfc6625/src/org/jitsi/impl/neomedia/transform/srtp/SRTPCipherCTROpenSSL.java#L63
so instead of silently truncating the 256bits key to 128bits, it now fails

Peter, did you successfully made AES256 call to another client than jitsi?

Regards
Etienne

>
> > Cheers,
> > Peter
>
> Ingo
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

https://github.com/jitsi/libjitsi/commit/e047367699445e05dfc04805afab75f8024e6d79

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.

You are right, AESFastEngine() was the only provider, and it support AES256
(
https://github.com/bcgit/bc-java/blob/da4d01b3e72a446ec0c7088aef8b38a2595e18a5/core/src/main/java/org/bouncycastle/crypto/engines/AESFastEngine.java#L610
)

I think it's not really hard to fix, even for the native code, but it's
really low on my todo list as AES256 isn't much more secure than AES128,
just slower.

https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

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.

Cheers
Etienne

···

2016-05-09 20:23 GMT+02:00 Ingo Bauersachs <ingo@jitsi.org>:

Ingo

> -----Original Message-----
> From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Etienne
> Champetier
> Sent: Montag, 9. Mai 2016 10:18
> To: Jitsi Developers <dev@jitsi.org>
> Subject: Re: [jitsi-dev] AES256 call fails
>
> Hi all,
>
>
> 2016-05-07 14:19 GMT+02:00 Etienne Champetier
> <champetier.etienne@gmail.com <mailto:champetier.etienne@gmail.com>
> >:
>
>
> 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.
>
>
> If you take a look at AES.java before my modifications, you have 4
> AES implementations, and all 4 are AES128:
> https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b59
> 9ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L644
>
> https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b59
> 9ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L663
> https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b59
> 9ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L680
> https://github.com/jitsi/libjitsi/blob/5aaaa52e1b38f4976bb7b071d26b59
> 9ecf308166/src/org/jitsi/impl/neomedia/transform/srtp/AES.java#L769
>
>
> In my modifications i've added some checks like the one you see/hit
>
> https://github.com/jitsi/libjitsi/blob/9237edaa82fce6208081685b7e0c29
> 55fcfc6625/src/org/jitsi/impl/neomedia/transform/srtp/SRTPCipherCTROp
> enSSL.java#L63
>
> so instead of silently truncating the 256bits key to 128bits, it now
> fails
>
>
> Peter, did you successfully made AES256 call to another client than
> jitsi?
>
>
> Regards
>
> Etienne
>
>
> >
> > > Cheers,
> > > Peter
> >
> > Ingo
> >
>
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

I've fixed this in libjitsi with PR#156 (https://github.com/jitsi/libjitsi/pull/156). Lyubomir, could you please review it?

Ingo

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Peter Villeneuve
Sent: Dienstag, 10. Mai 2016 18:13
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] AES256 call fails
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.

Cheers,

Peter