Really? You wrote custom crypto for this? Or do you use an SSL connection?

I wouldn't have thought to ask that. My original concern was: how do you assure someone like me that an attacker can't redirect files to other locations?

The protection against redirection is inherent in the underlying peer-to-peer media streaming technology we built on top of (RTMFP), as is the crypto. Going off your profile you seem to be a security researcher type. Would love to discuss things further with you offband. Feel free to email me directly, email is in my profile.

I don't believe that your email is there. I may take a whack at it later this week (we're launching a product and I'm pretty busy, but I do love me some custom crypto protocol.)

Please, please, please share your findings :) Your blog is the sad little feed in my Google Reader list that never gets any love, and, while I appreciate that you're getting shit done instead of entertaining the unwashed masses such as myself, I think this could be a great article. So again, please :)

A really old version of it - http://replay.waybackmachine.org/20060906221358/http://www.a...

Emailed you instead.

Interesting. How do you punch through NATs and firewalls? If you're doing it with p2p proxies, how do you do authentication and avoid mitm attacks?

If Sendoid is completely relying on RTMFP then the core security technology would have to be coming from Adobe. Check out Matthew Kaufmann's two year old talk on the subject: http://tv.adobe.com/watch/max-2008-develop/future-of-communi... Or Tom Krcha's blog which contains a number of Flash P2P entries: http://www.flashrealtime.com/ RTMFP is pretty fascinating technology that originates with a couple of very smart guys that Adobe brought on board (Matthew Kaufman and Michael Thornburgh). I'm curious if the Sendoid team has a non-Flash solution for 'restricted' devices.

If I understand RTFMP (what I know I got from reading Cumulus, an open source C++ implementation), the security side of this is not thrilling me:

* It's Diffie Hellman for key agreement, which is trivially MITM'd (odds are, you can even zero out the DH key and it won't notice).

* It uses AES in CBC mode with all-zeroes IV's (so it's less secure than CBC mode).

* It's using a 16 bit CRC for message integrity checks instead of a cryptographic MAC.

I say all this with the caveat that I could be misreading Cumulus or Cumulus could have it wrong, but if this is where RTMFP is today, then Sendoid is substantially less secure than an HTTPS file transfer site.

Thanks, and I'm hoping that part of flash works better than the video component on 64 bit linux.