3
$\begingroup$

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.

Improve this question
$\endgroup$
10
  • 1
    $\begingroup$ Why is this encrypt-and-MAC "generally not secure"? Any source/basis for saying that? $\endgroup$
    – axapaxa
    Commented Feb 19, 2017 at 17:41
  • $\begingroup$ @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. $\endgroup$
    – Ella Rose
    Commented Feb 19, 2017 at 17:51
  • $\begingroup$ @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. $\endgroup$
    – axapaxa
    Commented Feb 19, 2017 at 18:12
  • $\begingroup$ 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? ​ ​ ​ ​ ​ ​ ​ ​ $\endgroup$
    – user991
    Commented Feb 19, 2017 at 20:10
  • $\begingroup$ @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). $\endgroup$
    – Demi
    Commented Feb 19, 2017 at 21:28

1 Answer 1

Reset to default
2
$\begingroup$

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.)

Improve this answer
$\endgroup$
9
  • $\begingroup$ Yes, if the mac is computed over the message, and not the (randomized) ciphertext. $\endgroup$
    – K.G.
    Commented Feb 22, 2017 at 9:43
  • $\begingroup$ Have you looked at crypto.stackexchange.com/questions/202/… ? $\endgroup$
    – K.G.
    Commented Feb 22, 2017 at 20:19
  • $\begingroup$ I'm sorry, I was confused with Encrypt-then-MAC $\endgroup$
    – Daniel
    Commented Feb 22, 2017 at 22:02
  • $\begingroup$ And for the universal-hashing based MACs, the encryption of the MAC means that there is no leak. $\endgroup$
    – Demi
    Commented Feb 23, 2017 at 13:22
  • $\begingroup$ @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. $\endgroup$
    – K.G.
    Commented Feb 24, 2017 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.