0

I have using Crypto++ in Qt and use of AES Algorithm for encrypting files. I know about AES modes and their applications.

I have use of StreamTransformation method for encrypting files in CBC and EAX modes. Now I want to Transfer data over the network, but I don't know which of the AES modes are suitable for this application (which of them are faster and safer than others).

Also I research about RC4 algorithm, but I understand, this algorithm have lacks and known as an unSecure algorithm and RC4 should not be use in TLS protocol according to Mozilla and Microsoft.

techraf
  • 9,141
  • 11
  • 44
  • 62
  • 1
    Note: You should be using Crypto++'s built-in tools for (authenticated) encryption, e.g. [AuthenticatedEncryptionFilter](https://www.cryptopp.com/wiki/AuthenticatedEncryptionFilter) which will handle most of the complex stuff for you. – SEJPM Jun 25 '16 at 20:02
  • @SEJPM yes, i used of `AuthenticatedEncryptionFilter` instead of `StreamTransformationFilter` in EAX and CBC mode. – BattleTested_закалённый в бою Jun 26 '16 at 04:07

2 Answers2

5

You should always use an AEAD mode if you can, especially over the network. Crypto++ seems to support GCM, which is a good AEAD mode that has seen use in TLS 1.2. (There are others that are just as good, but TLS's "star power" lends GCM a lot of credibility.)

Importantly, AEAD modes authenticate "additional data." This is unencrypted data not included with the message, and is quite useful in network applications, as the additional data can contain a channel identifier of some kind (Either a TLS channel ID, a IP address and port combination, or something else appropriate to your protocol), and/or a timestamp. This prevents replay attacks by making the encrypted data only valid when it's sent over the original channel.

Reid Rankin
  • 1,062
  • 5
  • 10
  • what is your purpose about this ? **This prevents replay attacks by making the encrypted data only valid when it's sent over the original channel.** please more explain me. – BattleTested_закалённый в бою Jun 26 '16 at 04:32
  • Authenticated encryption modes verify that the message is valid as well as encrypting it. AEAD modes do that, but also verify "additional data" that is not part of the encrypted message. Essentially, whatever you choose to use for the additional dat gets hashed into the MAC component by the AEAD mode. – Reid Rankin Jun 26 '16 at 13:55
  • For example, if you use the TLS channel ID of the connection you're transmitting over as "additional data", the recipient will only successfully validate the message if they provide the same "additional data" during the decryption. Since the recipient gets the TLS channel ID not from the message but from their own TLS stack, transmitting the same (otherwise-valid) message over the wrong channel, as in a replay attack, will result in the recipient's validation failing. – Reid Rankin Jun 26 '16 at 14:01
  • You could also make your "additional data" the IP address of the person sending the message. This would have a similar effect. (Of course, you'd have to worry about proxies and NAT. Using a TLS channel ID is so much cleaner.) – Reid Rankin Jun 26 '16 at 14:03
1

McNerdHair is correct to require you to use an authenticated mode. There are more options than GCM mode though:

  • GCM mode is fast. It is sometimes called a 1.5 pass authenticated mode because of the fast GMAC calculation. It is standardized by NIST.
  • CCM mode is another NIST certified mode specifically created for packet encryption, i.e. transport mode security. It however has an exceedingly awkward and inflexible structure. It is somewhat slower than GCM as it calculates a normal CBC-MAC interally. In principle this is a perfect match but I'm probably not alone in disliking the internal structure.
  • EAX mode is usually about as fast as CCM, but it has a more flexible design than GCM & CCM. It allows you to add Additional (Authenticated) Data (AD or AAD) after encrypting. It may also be somewhat more secure, especially if shorter authentication tags are used. It has been taken into account by NIST but it hasn't been standardized.
  • ChaCha / Poly1305 as you've also shown interest for fast stream ciphers such as RC4 you might consider the more up-to-date streaming algorithms as used by the latest iterations of TLS. This combination should make for fast operations, especially for pure software libraries.
Maarten Bodewes
  • 4,562
  • 15
  • 29