[Live-devel] Encrypting rtp stream

[Warren Young]

On Feb 21, 2019, at 4:42 PM, Kevin Bailey <kevin at pudle.io> wrote:
> 
> the amount of data being encrypted needs to match the amount of data received on the client end. Or at the very least the number of packets going out and coming in need to be the same. I found that neither is the case.

I believe you’re trying to reinvent length-preserving encryption:

    https://crypto.stackexchange.com/questions/6098/is-there-a-length-preserving-encryption-scheme

Such schemes have many other purposes, such as hard disk encryption, since you don’t really want to be reserving some percentage of the drive’s sectors for encryption overhead.

Don’t try to roll your own encryption.  Just don’t.  Leave this to experts.

Even better, don’t reinvent your own protocol stacks.  Ross’ answer to implement a standard protocol is better than taking standard pieces from multiple places (e.g. Live555 + OpenSSL) and try to come up with a working mashup.  People get encryption wrong all the time and end up creating something insecure that happens to *look* secure until someone with a clue gets their hands on it.

I suspect Ross wouldn’t immediately turn down an implementation of SRTP, if one were offered under a suitable license.