ENCRYPT DATA WITH GCM

[dangvohoanganhvn]

Hi zenomt, Your example is using CBC to encrypt data between sessions. Can I replace it with GCM? is there any problem with GCM as in my research GCM has a better performance than CBC. Does GCM cause rtmfp overhead in some cases that I don't realize ?

[zenomt]

the FlashCryptoAdapter uses AES-128-CBC because that is the only cipher defined in RFC 7425. RTMFP isn't limited to AES-128-CBC, but the Cryptography Profile for Flash Communication is.

you of course can create your own cryptography profile (either from scratch, or deriving from the Flash Communication profile) that uses GCM (or any other cipher), and create your own ICryptoAdapter that implements it (again either from scratch or by subclassing or starting from the FlashCryptoAdapter).

you will need to define where to put the IV and the Auth Tag in packets. these shouldn't be much more packet overhead than the session sequence number and HMAC fields for Flash Crypto (which should always be used, and are on by default in all of my examples), especially since the cipher text of GCM is the same size as the plaintext, while CBC is always a multiple of the cipher block size (16 bytes).

using GCM with a proper IV might make security analysts happier too. as described in the Security Considerations of RFC 7425, the Flash Cryptography Profile uses the same (implicit, null) IV for every packet, which can reveal to an observer if two packets contain identical plaintext. this is the main reason you should always use a session sequence number in Flash Crypto, since that guarantees every packet's first cipher block is unique.

recall from the Introduction of RFC 7016 that "interoperation between applications of RTMFP requires common or compatible Cryptography Profiles". GCM would not be compatible with other RTMFP applications that just use the Flash profile.

[dangvohoanganhvn]

Thanks for your very helpful explain.

[ROBERT-MCDOWELL]

@zenomt but as RTMFP is open source now, why not to create an official RTMFP repo with new crypto and else so maybe it will push maintaining RTMFP application to evolve too?

[zenomt]

i no longer work for Adobe, so all of my RTMFP work is "unofficial" now. note that this repo is a new implementation based on the public specifications (that i wrote ;) ), and is a labor of "love" rather than of "business".

creating a new cryptography profile isn't high on my list of priorities, especially since i don't have a good sense of how many people actually care about RTMFP, or who would use it if only it used a different cipher. if i was going to make new divergent changes to the cryptography profile, it would probably be to use FIPS-compliant crypto, like AES-256, the newer/bigger SHA algorithms, disabling the smaller Diffie-Hellman groups, and possibly switch to using an explicit IV that includes the session sequence number rather than using a sequence number in the plaintext (even though it's cryptographically sound for AES).

for the time being, though, "please add a GCM crypto adapter to this repo" will be a "wontfix".

[zenomt]

the original question was answered. there are no plans to add GCM or otherwise diverge from the RFC 7425 cryptography profile any time soon. closing as "wontfix".