256 bit encryption for DTLS-SRTP


Our customer has requirement of having 256 bit encryption for webrtc data.

What are the steps to make this happen? Is it possible? I’m ok to make code changes myself and share it back to the community, if I get it working.

Isn’t it already using at least 1024 key length?

tls ciphers depends both on client and server. If you tcpdump dtls exchange, you’ll see that firefox and chromium don’t offer the same ciphers in the client hello (Firefox offer more advanced ones - I think that ChaCha is rating 256 on key size).
In my server case, server code picks the same cipher with both browsers (AES128) - but it could depend on the java version, and possibly the certificates installed. I have never seen any doc on the specific Jitsi subject, but there could be info about generic Java servers with web clients that could be adapted.

As the link states, chrome uses 128 bit ECDSA keys. 1024 RSA keys are not as secure. And it is about DTLS. I already successfully changed DTLS encryption of video bridge to 256 bit.

Video is encrypted with SRTP (I had wrote it wrong on title), jitsi videobridge supports only 128 bit encryption ATM. Both chrome and Firefox can support 256 bit also. https://tokbox.com/developer/guides/advanced-media-stream-encryption/

Can I modify the title somehow to have DTLS-SRTP instead of dtls-rctp?

Calling the cavalry @Jonathan_Lennox @bbaldino any thoughts on this? Thanks.

Jonathan can probably give a more complete answer, but the code where we list SRTP protection profiles is here

We’d first need to support AES-GCM SRTP – there’s no DTLS/SRTP codepoint for negotiation of 256-bit AES-CM encryption.

That’s on my to-do list to add, though. (Most of the work would be in the jitsi-srtp module.)

Once that’s done supporting 256-bit AES/GCM SRTP would be pretty straightforward, assuming browsers also support it.

That’s how far I got with my research. With further research: javax.crypto seems to have support for AES GCM, so I will give a try for it.

Also I took a look into jitsi-srtp, was easy to read and we’ll documented code, so doesn’t seem to be too hard to implement.

I have implemented the encryption by using https://github.com/cisco/libsrtp library.

I choose to not use Java, because the support in javax.crypto is not fully implementing the features and there are too many security related issues I should not be doing.

Libsrtp implementation with JNI bridge and it seems to perform quite well, based on SrtpPerfTest, it seems to be faster than AES 128 CM:
AES-128-GCM: Executed 100000000 SRTP enc/auth (1250 byte payload) in PT10M54.057222S: 6,540 µs/pkt
AES-256-GCM: Executed 100000000 SRTP enc/auth (1250 byte payload) in PT13M46.626207S: 8,266 µs/pkt
AES-128-CM: Executed 100000000 SRTP enc/auth (1250 byte payload) in PT16M55.693302S: 10,156 µs/pkt

I have one issue though, when I run Jitsi Videobridge server, some of the RTCP packets lengths are going over the buffer length. And that might cause connections to drop at some point. The first log is my debug log to show related packet info. Where the buffer is allocated? Do you know if I can determine safe size to be allocated?

Aug 17, 2020 8:26:07 AM org.jitsi.utils.logging2.LoggerImpl log
INFO: doSendSrtp : buffer.length 220, offset 0, length 224
Aug 17, 2020 8:26:07 AM org.jitsi.utils.logging.LoggerImpl log
WARNING: Failed to handle packet: 
java.lang.IllegalArgumentException: illegal length or offset
	at java.net.DatagramPacket.setData(DatagramPacket.java:267)
	at java.net.DatagramPacket.<init>(DatagramPacket.java:84)
	at org.jitsi.videobridge.transport.ice.IceTransport.send(IceTransport.kt:222)
	at org.jitsi.videobridge.Endpoint.doSendSrtp(Endpoint.java:482)
	at org.jitsi.nlj.util.PacketInfoQueue$sam$org_jitsi_utils_queue_PacketQueue_PacketHandler$0.handlePacket(PacketInfoQueue.kt)
	at org.jitsi.utils.queue.PacketQueue$HandlerAdapter.handleItem(PacketQueue.java:575)
	at org.jitsi.utils.queue.AsyncQueueHandler$1.run(AsyncQueueHandler.java:141)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Very interesting stuff @Joe_y

I’m also interested in exploring this further. Do you mind sharing the code for your implementation of AES 256 GCM?


I have other priorities at the moment, but I will get back on this next month. I will put changes public on Github then.

1 Like

Great. Looking forward to it.

Hi @Joe_y

Have you had time to publish the changes on github yet?

Would love to study this more in depth.


Sorry, not yet… We are publishing new big release of our software in up coming weeks, which takes all of my time.

1 Like

I don’t think we’ve seen this issue…could you try adding some logs to log the length of the buffer and the values of offset and length? Encrypt is pretty much at the end of the send pipeline, so if you’ve got changes there then something might be going awry that’s caught here.

No worries. Fully understandable.
Good luck with your new release.

I’ll keep monitoring this thread and hopefully you’ll have more time for this again soon.


For now, I have changed value of T1 variable to 260 here https://github.com/jitsi/jitsi-videobridge/blob/master/jvb/src/main/java/org/jitsi/videobridge/util/ByteBufferPool.java#L43

It works at least on my own testing. According to the comment they were any way determined by testing. I will provide more info, if there are still problems.

1 Like

AES-GCM, including configurable 256-bit support, is now supported in jitsi-videobridge.

AES-GCM-128 is enabled by default; AES-GCM-256 can be enabled by changing the configuration in jvb.conf.


Thanks Jonathan! Great progress!!

What’s the exact config to enable AES-GCM-256?

My jvb.conf has

videobridge {
http-servers {
public {
port = 9090
websockets {
enabled = true
domain = “jitsi.mydomain.com:443
tls = true