3

OpenSSH will (especially in older versions) use AES-CTR plus a MAC in encrypt-and-MAC. This is not secure in general (meaning that there exist secure ciphers and secure MACs such that using them in encrypt-and-MAC is insecure).

However, as I understand it AES-CTR + MAC as used in SSH is secure, at least for the MAC choices actually in use, because:

  1. The MACs used (HMAC and UMAC/VMAC + encrypt the MAC tag) are privacy-preserving: the MAC tag does not leak any information about the plaintext, at least for one who does not know the MAC key. In the case of HMAC, I believe that this follows from HMAC being a strong PRF; in the case of UMAC/VMAC, the security of the MAC depends entirely on encrypting the MAC before transmission, and the encryption of the MAC also ensures that no information about the plaintext is leaked.

  2. No encoding is done between encryption and authentication. The data that is encrypted and the data that is authenticated are one and the same.

  3. The cipher in question uses CTR mode – in other words, it is a stream cipher. Thus, any change to the ciphertext will cause a 1-to-1 change in the plaintext – integrity of plaintext thus implies integrity of ciphertexts.

My conclusion is that these cipher suites are actually secure, due to the specifics of the protocol.

Is my reasoning correct? More importantly, is my conclusion correct? I am not a cryptographer and have zero trust that I did not make a foolish error.

Demi
  • 4,793
  • 1
  • 19
  • 39
  • 1
    Why is this encrypt-and-MAC "generally not secure"? Any source/basis for saying that? – axapaxa Feb 19 '17 at 17:41
  • @axapaxa Have you seen the canonical Q about combining macs and encryption here on the site? If there's an answer to your question, you should find it there. – Ella Rose Feb 19 '17 at 17:51
  • @EllaRose I actually checked before saying that. There is nothing about encrypt-and-MAC being broken, it simply has less resistance against cipher/hash breakage (and AES isn't broken). There is nothing about it "being generally insecure", but it isn't recommended in new systems (just like for example 3DES). So still no source/basis for that. – axapaxa Feb 19 '17 at 18:12
  • In fact, I would venture that most MACs are such that regardless of the encryption scheme, using the MAC "in encrypt-and-MAC is insecure" (due to revealing, when encryptions are of the same message, with no false-negatives and a false-positive rate that is bounded above by their forgeability). ​ For that reason: ​ ​ ​ Are you sure they're really expected to be privacy-preserving in the sense you describe, rather than just satisfying the usual definition of PP-MAC, which allows them to leak message equality? ​ ​ ​ ​ ​ ​ ​ ​ –  Feb 19 '17 at 20:10
  • @RickyDemer Didn't think of message equality. MACs based on encrypting the output of a universal hash with a stream cipher are immune to that though. The attack is also foiled for any PP-MAC if the authenticated data includes a message number (which I believe it does in the case of SSH). – Demi Feb 19 '17 at 21:28
  • Do the message-encryption and uhash-encryption bits come from (different positions in) the same stream or from (computationally-independent) separate streams? ​ ​ –  Feb 19 '17 at 23:22
  • @RickyDemer Don't know, but it shouldn't matter — an adversary should not be able to distinguish them. – Demi Feb 19 '17 at 23:24
  • How universal is the hash family? ​ (When just one stream is used, I can make security fail at $\hspace{.57 in}$ the cost of reducing universally by at most double the probability of predicting a hash output.) $\hspace{.47 in}$ –  Feb 20 '17 at 00:13
  • @RickyDemer How can you make that happen, for a non-contrived hash? – Demi Feb 23 '17 at 21:57
  • I don't see any way of doing it with a non-contrived hash. ​ ​ –  Feb 23 '17 at 21:58

1 Answers1

2

Encrypt-and-MAC does not preserve confidentiality because two encryptions of the same message will have the same mac tag, revealing the fact that the messages are equal.

Ssh includes a counter in the data the mac tag is computed over, so it never computes the mac tag for the same message twice (even if identical data is transmitted twice), so this particular weakness is not an issue.

This is not an endorsement of encrypt-and-MAC, however. Do not use it.

(If you have a strange MAC, encrypt-and-MAC can leak even more than equality, but few reasonable MACs are strange.)

K.G.
  • 4,617
  • 16
  • 32
  • Yes, if the mac is computed over the message, and not the (randomized) ciphertext. – K.G. Feb 22 '17 at 09:43
  • Have you looked at http://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac?noredirect=1&lq=1 ? – K.G. Feb 22 '17 at 20:19
  • I'm sorry, I was confused with Encrypt-then-MAC – Daniel Feb 22 '17 at 22:02
  • And for the universal-hashing based MACs, the encryption of the MAC means that there is no leak. – Demi Feb 23 '17 at 13:22
  • @Demi I don't really understand your comment. If you have a deterministic MAC, E&M leaks message equality. If you have a randomised MAC, it may not leak anything, but these are rare. If you have a stateful MAC, it may not leak anything, but these are rare. If you do not use plain E&M, but some other construction, it may not leak anything. – K.G. Feb 24 '17 at 07:57
  • @K.G. Typical MACs based on universal hashing are stateful, since they use a stream cipher to encrypt the hash output. As a result, no information is leaked. – Demi Feb 24 '17 at 14:10
  • @Demi I did not know typical universal hash-based MACs were stateful. Examples? – K.G. Feb 24 '17 at 20:43
  • @K.G. Consider Poly1305-AES. It computes an almost-universal hash of the message, and then XORs it with a nonce encrypted using AES. The nonce must not be used more than once – if it is, all security is lost. If the nonce is used only once, however, the security reduces to that of AES, and no information about the message leaks through to the MAC. – Demi Feb 24 '17 at 22:18
  • @Demi An algorithm isn't stateful just because it uses a nonce. – K.G. Feb 26 '17 at 12:18