Hi there,
This would still require both, client and server, to receive an update to support these new algorithms. So I wonder what would be the benefit of having those over strict key exchange? Also, existing security proofs for ChaCha20-Poly1305 and Encrypt-then-MAC constructions in SSH would become meaningless then.So there could be a Chacha20-Poly1305v2@xxxxxxxxxxx which uses AD data to chain the messages together, so it will be resistant against terrapin even without the strict-kex. Consequently the hmac-etmv2@xxxxxxxxxxx mode could be deviced in a similar manner, to also include the transcript hash or similar things.
Yes, we did. We describe this mode as "vulnerable, but not exploitable" in our paper. Terrapin works against the general Encrypt-then-MAC construction, although some cipher specifics may prevent exploitation in a real world scenario. In this case, dropping a message from the secure channel causes the AES-CTR keystream to become out of sync (similar issue with stream ciphers like arcfour, just for reference). As far as we are aware, there is no way for an attacker to realign the keystream to allow the session to continue. Note however, that the attack still passes MAC verification and that an exception is only thrown at the application layer (i.e. wrong message format of SSH_SERVICE_REQUEST / _ACCEPT).Has anybody analyzed the aes-ctr / hmac-etm properties, whats making this resist and is it rigid? It looks like it is only the counter position which saves it?
From our current point of view, this combination can be used without risking any real world attack. However, this may change if someone finds a way to realign the keystreams. We suggest disabling Encrypt-then-MAC over CBC as a workaround to be on the safe side here. I'd also like to stress that this workaround is only meant as temporary stop-gap measure until patches are available.So is keeping hmac-etm iff aes-ctr is offered used still a safe option (or just "not broken"). Because luckily many have removed CBC already.
And while "enforce strict-key" could gain some of the trust back, the attack also shows, that those constructs are just very fragile.
For reference, there has been a similar request over on Ars Technica. M. Sc. Fabian Bäumer Chair for Network and Data Security Ruhr University Bochum Universitätsstr. 150, Building MC 4/145 44780 Bochum Germany Am 20.12.2023 um 11:57 schrieb Bernd Eckenfels:
Hello, in addition to my last thread about a new config option to make strict-kex mandatory, I also wonder if a new mechanism for ciphers/macs can be introduced and is reliable by simple both sides using it. So there could be a Chacha20-Poly1305v2@xxxxxxxxxxx which uses AD data to chain the messages together, so it will be resistant against terrapin even without the strict-kex. Consequently the hmac-etmv2@xxxxxxxxxxx mode could be deviced in a similar manner, to also include the transcript hash or similar things. The impact of removing the only "alternative" cipher cc20p1305 because of terrapin hardening as well as falling back to the old eam-macs is really bad for ssh best practice. And while "enforce strict-key" could gain some of the trust back, the attack also shows, that those constructs are just very fragile. And while a redesign of the protocol might be a good option, its not the fastest to standardize and implement. Whereas openssh project has done it before both new ciphers. On that note - maybe combine it with PQ hybrid modes? I have a related question: Has anybody analyzed the aes-ctr / hmac-etm properties, whats making this resist and is it rigid? It looks like it is only the counter position which saves it? So is keeping hmac-etm iff aes-ctr is offered used still a safe option (or just "not broken"). Because luckily many have removed CBC already. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Attachment:
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
