[Red5] RTMPE handshake breakdown

[Peter Thomas]

Hi,

Some good news, thanks to this very handy excel sheet I was able to fix a
couple problems that was holding up my Java RTMPE client-side implementation
and now it is working !!

You can find all the details here:

http://flazr.svn.sourceforge.net/viewvc/flazr/trunk/flazr/src/main/java/com/flazr/Handshake.java?revision=5&view=markup

You can see that I am using standard Java crypto stuff.  Also, I am using
Apache Mina (just like Red5) and here is the filter code for the encryption
/ decryption layer:

http://flazr.svn.sourceforge.net/viewvc/flazr/trunk/flazr/src/main/java/com/flazr/RtmpeIoFilter.java?revision=5&view=markup

I am pretty sure that with this done, RTMPE support for Red5 is just a
matter of time.  Feel free to ask me questions.

Thanks again to Gavriloaie Eugen-Andrei [ http://www.rtmpd.com ] for the
handshake analysis and for helping me today over chat and of course to Luke
[ http://lkcl.net/rtmp ] for making all of this possible.

Regards,

Peter.

P.S. maybe you should do an SVN checkout of the code before it disappears :P

On Wed, Jun 3, 2009 at 2:27 PM, Daniel Rossi <electroteque at gmail.com> wrote:

>
> On 03/06/2009, at 6:44 PM, Gavriloaie Eugen-Andrei wrote:
>
> On Jun 3, 2009, at 11:14 AM, Daniel Rossi wrote:
>
> Is this of importance so basically an extension to the current handshake ?
> if (encrypted) {
>         //prepare the in/out keys
>         uint32_t clientDHOffset = GetDHOffset(pInputBuffer + 1532);
>         uint8_t secretKey[128];
>         if (DHComputeSharedSecretKey(pDH, pInputBuffer + clientDHOffset,
> 128, secretKey) != 128) {
>             FATAL("Unable to compute shared");
>             return false;
>         }
>
>         _pKeyIn = new RC4_KEY;
>         _pKeyOut = new RC4_KEY;
>         InitRC4Encryption(
>                 secretKey,
>                 (uint8_t*) & pInputBuffer[clientDHOffset],
>                 (uint8_t*) & _pOutputBuffer[serverDHOffset],
>                 _pKeyIn,
>                 _pKeyOut);
>
>         //bring the keys to correct cursor
>         uint8_t data[1536];
>         RC4(_pKeyIn, 1536, data, data);
>         RC4(_pKeyOut, 1536, data, data);
>     }
>     DHFree(pDH);
>
> So just have to figure out what DHComputeSharedSecretKey is and what it
> does ? Is this a library method ?
>
> Is the shared key from DH key pair and remote DH public key. In java you
> can generate secretKey using a KeyAgreement.
> For example, suppose we have 2 endpoints: A and B. Both endpoints have a DH
> key pair, thus we have:
>
> DHa - DH key pair from endpoint A
> DHb - DH key pair from endpoint B
>
> DH key pair has 2 keys: public key and private key. Thus we have:
> DHaPublic
> DHaPrivate
> DHbPublic
> DHbPrivate
>
> Both endpoints can compute a shared key like this:
>
> SharedA = KeyAgreement(DHa, DHbPublic) - using key pair A and public B
> SharedB = KeyAgreement(DHb, DHaPublic) - using key pair B and public A
>
> SharedA MUST be equal with SharedB and is guaranteed by the DH algorithm.
> You can use this like a verification to test the DH algorithm.
>
> In java, all this is made by a KeyAgreement class/interface in javax.crypto
> but i can't tell you precisely which one. Sorry... :(
>
> _pKeyIn and _pkeyOut are RC4 keys for encrypting/decrypting the future
> traffic (immediately after the handshake)
>
> They are computed using a wrapper function called InitRC4Encryption.
> Inside, the _pKeyIn and _pkeyOut are initialized with first 16 bytes from
> HMACSha256 over correspondin DH public keys using secretKey as key.
> The implementation is located here:
> http://www.rtmpd.com/browser/trunk/sources/thelib/src/utils/dh.cpp
>
>
> Yep I was wondering where the wrapper functions were ;)
>
>
> REMEMBER to encrypt decrypt something (random data) immediately after the
> computing the in/out keys. The block must have the size of 1536. This will
> bring the keys to the correct values. RC4 keys are changing after each
> encryption/decryption. They are dynamic. If you don;t do that, your
> algorithm will not work. Man.... I've spent 4 hours in my case figuring that
> out until I've looked with much more attention in the rtmpdump sources.
>
>
> Btw... many thanks to Luke for making this possible
>
> Also I'm reattaching that excel file because I forgot to explain the
> regions :P
>
>
> Best regards,
> Andrei
>
> <server.xlsx>
>
>
>
> On 03/06/2009, at 5:52 PM, Gavriloaie Eugen-Andrei wrote:
>
> Hi,
>
> I've made an excel sheet with the every zone in the client/server
> handshake. Together with the source links below, I hope it is much easy to
> implement.
> I sincerely can't work in java because I have to invest too much time to
> learn it in order to be at least productive if not proficient.
> I prefer to invest that time in documents for example.
>
>
> http://www.rtmpd.com/browser/trunk/sources/thelib/src/protocols/rtmp/inboundrtmpprotocol.cpp
>
> http://www.rtmpd.com/browser/trunk/sources/thelib/src/protocols/rtmp/outboundrtmpprotocol.cpp
> <server.xlsx>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090603/4189794d/attachment.html>