Hi Gerhard, This is not exactly true. CTR modes have the length field encrypted. etm MAC modes and AES-GCM have the length field in cleartext. CBC is dangerous because the length field is encrypted with CBC. aes128-ctr + hmac-sha256 doesn't have any known vulnerability and encrypts the packet length, but uses the bad practice of e&m. chacha20-poly1305 encrypts both payload and packet len + uses authenticated encryption (best practice), even if the implementation looks very similar to etm. Aris>> BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they >> disclose packet length. >> https://wiki.mozilla.org/Security/Guidelines/OpenSSH >> Any comments on this? >> > > Jan answered me, as the packet length is transmitted in plaintext, see: > http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html > > Ciao, > Gerhard > > -- http://www.wiesinger.com/ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
On 16.06.2015 14:43, Aris Adamantiadis wrote:> Hi Gerhard, > > This is not exactly true. CTR modes have the length field encrypted. > etm MAC modes and AES-GCM have the length field in cleartext. > CBC is dangerous because the length field is encrypted with CBC. >What's exactly the topic encrypting the length field with CBC? Any documentation/papers on this to understand (except the source)?> aes128-ctr + hmac-sha256 doesn't have any known vulnerability and > encrypts the packet length, but uses the bad practice of e&m. > chacha20-poly1305 encrypts both payload and packet len + uses > authenticated encryption (best practice), even if the implementation > looks very similar to etm. >Why is E&M bad practice? Thank you. Ciao, Gerhard
On 18/06/15 19:25, Gerhard Wiesinger wrote:>> aes128-ctr + hmac-sha256 doesn't have any known vulnerability and >> encrypts the packet length, but uses the bad practice of e&m. >> chacha20-poly1305 encrypts both payload and packet len + uses >> authenticated encryption (best practice), even if the implementation >> looks very similar to etm. >> > > Why is E&M bad practice?First of all Encrypt-and-MAC (E&M) allows an attacker to recognise two identical messages due to the shared MAC. The ideal method of composing ciphers and macs is to use Encrypt-and-MAC, which has the very nice property of not decrypting anything before authenticating it. For instance, a common error is to fail early (in a way noticeable by timing) before checking the mac (eg. such as noticing that the plaintext is corrupt). Colin Percival explains in http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html how only Encrypt-then-MAC is provably secure. See http://cseweb.ucsd.edu/~mihir/papers/oem.pdf for the detailed proof comparing the modes.