On Feb 21, 2019, at 4:42 PM, Kevin Bailey <[email protected]> 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.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
